• conveniently sandboxed firefox browser

    From Big Bad Bombastic Bob@21:1/5 to All on Thu Apr 28 08:44:04 2022
    I have several 'no privilage' logins on my FreeBSD workstation that I
    have made convenient for sandboxed browsing. Sometimes the browser is configured to automatically purge ALL history and cookies and data on
    exit. Other times it is just so I am not tracked outside of what I do
    directly on a specific service, like Slack (for work), or more recently, Twitter because Musk is buying it.

    Here is how it works:

    * X11 server must be listening via TCP so that you can use
    export DISPLAY=:0.0
    when you run stuff and it will connect
    * use 'xhost +localhost' before starting the sandboxed application
    (the run-as script will do this for you)
    * create the scripts you see below, put them in the path
    with appropriate names
    * create a user for each application in which you want to run a sandbox
    Each user should have your id_rsa.pub string in the
    .ssh/authorized_keys file (a password prompt causes hangs
    so this is a 'must' step)
    * set up link buttons or menus that run something like this:
    run-as-GUI luzer firefox --new-instance http://track-me.com/
    where 'luzer' is the user firefox runs under. Adjust the user name
    and URL as appropriate.

    It will then run firefox (or whatever) under that user name on your X11
    desktop and sandbox everything that happens, including browser history,
    links, plugins, whatever. You can allow script and not worry about
    viruses or tracking (if you purge history) and if it poses a problem,
    just delete the home dir and user and re-create it. Simple.

    Here are the scripts:

    run-as-GUI (you will need to adjust this for your desktop and path)
    ----------
    #!/bin/sh

    mate-terminal -x /home/my-user-name/bin/run-as $@

    ----------

    run-as
    ------

    !/bin/sh

    if test -z "$2" ; then
    echo Usage: run-as username command [arglist]
    echo ""
    echo This will run the specified \
    '('GUI')' command via ssh as that user
    echo If you do not want to be prompted for a password, set up the
    echo user to allow an ssh cert to authenticate '('man ssh-keygen')'
    echo ""
    echo press enter key to exit
    pause
    exit
    fi

    xxx=`xhost | grep INET:localhost`
    if test -z "$xxx" ; then
    echo adding localhost as authorized to connect to this X server
    xhost +localhost
    fi

    uuu="$1"
    shift

    ssh -f -l $uuu localhost "env DISPLAY=127.0.0.1:0.0 $@ &"

    ------


    --
    (aka 'Bombastic Bob' in case you wondered)

    'Feeling with my fingers, and thinking with my brain' - me

    'your story is so touching, but it sounds just like a lie'
    "Straighten up and fly right"

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Tavis Ormandy@21:1/5 to Big Bad Bombastic Bob on Fri Apr 29 15:53:16 2022
    On 2022-04-28, Big Bad Bombastic Bob wrote:
    * use 'xhost +localhost' before starting the sandboxed application
    (the run-as script will do this for you)

    The problem is that this is enough to let the unprivileged users take
    over your session. They can send fake keystrokes and mouse events to
    other clients to start an xterm and then send commands, for example.

    There is an easy solution! You can use untrusted cookies (see xauth(1)),
    this limits what they're allowed to do, no screenshots no fake events,
    etc).

    It requires the SECURITY extension (try xdpyinfo -queryExtensions).

    Tavis.

    --
    _o) $ lynx lock.cmpxchg8b.com
    /\\ _o) _o) $ finger taviso@sdf.org
    _\_V _( ) _( ) @taviso

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Big Bad Bombastic Bob@21:1/5 to Tavis Ormandy on Mon May 2 05:05:13 2022
    On 4/29/22 08:53, Tavis Ormandy wrote:
    On 2022-04-28, Big Bad Bombastic Bob wrote:
    * use 'xhost +localhost' before starting the sandboxed application
    (the run-as script will do this for you)

    The problem is that this is enough to let the unprivileged users take
    over your session. They can send fake keystrokes and mouse events to
    other clients to start an xterm and then send commands, for example.

    There is an easy solution! You can use untrusted cookies (see xauth(1)),
    this limits what they're allowed to do, no screenshots no fake events,
    etc).

    It requires the SECURITY extension (try xdpyinfo -queryExtensions).

    Tavis.


    yeah if I were running applications you would definitely be correct. At
    this point I am mostly concerned about trackers and zero day exploits. Something as complicated and sophisticated to do what you described,
    without intimiate knowledge of the system it is running on, might be
    next to impossible.

    Good info, though. I'll look into that at least to satisfy my curiosity.


    --
    (aka 'Bombastic Bob' in case you wondered)

    'Feeling with my fingers, and thinking with my brain' - me

    'your story is so touching, but it sounds just like a lie'
    "Straighten up and fly right"

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)