poor-man's sandbox (for web browser security, etc.)

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

poor-man's sandbox (for web browser security, etc.)

Joel Rees-2
I don't know whether this is a good idea, a bad idea, or worth the
trouble, but I've used sudo to make a poor-man's sandbox in the past,
like this:

http://reiisi.blogspot.jp/2011/08/simple-sandbox-for-firefox.html

Trying this on openbsd seems to work:

-------------------------------
# Added a new login class:
vi /etc/login.conf
...
hexed:\
        :auth=reject:\
        :shell=/sbin/nologin:\
        :datasize-cur=512M:\
        :datasize-max=1024M:\
        :maxproc-max=128:\
        :maxproc-cur=64:\
        :requirehome@:\
        :tc=default:
...

mkdir /home/x/hexed-me

groupadd -g 7734 hexed-me

useradd -b /home/x -g hexed-me -u 7734 -L hexed hexed-me

chown hexed-me:hexed-me /home/x/hexed-me

# Changed the default shell for hexed-me:
vipw
...
hexed-me:*:7734:7734::/home/x/hexed-me:/sbin/nologin
...

usermod -G hexed-me me

chmod -R o-rwx,g+rwx /home/x/hexed-me

# Added the following to /etc/sudoers
# (actually, to /etc/sudoers.d/hexed-me, via #includedir):
visudo
...
User_Alias HEXEDMEDOER = me
Runas_Alias HEXEDMEHEXED = hexed-me
Defaults:HEXEDMEDOER !authenticate, always_set_home, set_logname,
!preserve_groups
HEXEDMEDOER ALL = (HEXEDMEHEXED) ALL
...
# (Had to chmod 550 /etc/sudoers.d and chmod 440 /etc/sudoers.d/hexed-me .)

# Didn't need to make this script:
vi bin/firehex
===
#! /bin/sh

xhost local:${1}; sudo -u ${1} firefox $2
===
-------------------------------

It seems to run firefox just fine:

sudo -H -u hexed-me firefox

but gedit doesn't change to hexed-me's home directory run the same way.

I would appreciate any critiques or out-right criticisms of this.

Is it worth the trouble?

Does it perhaps open up new vulnerabilities instead?

--
Joel Rees

Be careful when you look at conspiracy.
Look first in your own heart,
and ask yourself if you are not your own worst enemy.
Arm yourself with knowledge of yourself, as well.

Reply | Threaded
Open this post in threaded view
|

Re: poor-man's sandbox (for web browser security, etc.)

Jonathan Thornburg-3
In message <http://marc.info/?l=openbsd-misc&m=141848398918562&w=1>,
Joel Rees wrote:

> I've used sudo to make a poor-man's sandbox in the past,
> like this:
>
> http://reiisi.blogspot.jp/2011/08/simple-sandbox-for-firefox.html
>
> Trying this on openbsd seems to work
>
> [[...]]
>
> It seems to run firefox just fine:
>
> sudo -H -u hexed-me firefox
>
> [[...]]
>
> I would appreciate any critiques or out-right criticisms of this.
>
> Is it worth the trouble?
>
> Does it perhaps open up new vulnerabilities instead?

This is better than nothing, but it still gives the firefox process
unlimited access to the X protocol and (through the X protocol) the
X server.  If firefox process were to be pwned (e.g., a drive-by web
attack were to exploit a firefox buffer overrun), you could have
malicious code doing some very nasty things.  For example:
(a) create a transparent window covering the entire screen, i.e.,
    a keylogger, and use this to sniff passwords
(b) write to various user-hexme scripts to make the exploit persistent
(c) inject malicious input (e.g. 'rm -rf $HOME &') into various shells
(d) send anything stored in the firefox password manager to evil.com

I outlined some ideas for mitigating some of these risks in the thread
starting at <http://marc.info/?l=openbsd-misc&m=141616701418506&w=1>;
lots of people responded with useful suggestions.  Basically, my proposal
was (is) to run firefox as a separate nonpriviliged user, but via an
ssh -X tunnel to localhost, using public-key authentication:

  #!/bin/sh
  ssh -X -i $HOME/.ssh/firefox _firefox@localhost \
      firefox.bin -no-remote -new-instance \
      2>&1 >/dev/null &

This means that the firefox process is subjected to the X11 Security
Extension restrictions, which (in theory) would prevent the firefox
process from interfering with other X clients.  That is, in theory this
approach blocks exploits (a) and (c).

I've been using this for a while now on 5.6-stable/amd64, and it works
pretty well.  The main problem I've found so far is with X cut-n-paste;
in <http://marc.info/?l=openbsd-misc&m=141721398509425&w=1>, tedu@
pointed out that this is a feature, not a bug, of the way X security
works.  The result is:
* cut-n-paste from other clients into firefox works fine
* cut-n-paste from firefox out to other clients doesn't work;
  a shell script like this provides an "80%" workaround to access
  the cut-n-pasted-from-firefox text

  #!/bin/sh
  ssh -X -i $HOME/.ssh/firefox _firefox@localhost \
      xsel -o
  echo ''

  I suspect that a slightly fancier script could then insert that text
  back into the regular outside-the-sandbox X cut buffer, but I haven't
  gotten around to trying that yet.

ciao,

--
-- "Jonathan Thornburg [remove -animal to reply]" <[hidden email]>
   Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA
   "There was of course no way of knowing whether you were being watched
    at any given moment.  How often, or on what system, the Thought Police
    plugged in on any individual wire was guesswork.  It was even conceivable
    that they watched everybody all the time."  -- George Orwell, "1984"