A new kind of security needed

[xorquewasp at googlemail.com]

> Is anyone else nervous trusting all his programs to have access to all
> his files? Is there already a reasonable solution to this problem?

I suppose it depends what you're after and how much work you're willing
to put in. I can't define "reasonable" but certainly, with a bit of work
somebody could release a package that automates everything I'm about to
outline.

I have a setup here using four or five jails built with sysutils/ezjail
(so they're very lightweight - nullfs).

All jails are bound to unrouteable IPs (127.1.0.*). Packets are
forwarded using pf binat with a very paranoid ruleset.

Jail 1 is 'untrusted' in the sense that it's used for programs that
shouldn't have access to the host filesystem or the network. The
principle is that of least privilege - if ANY program doesn't need
network access, it's run in this jail.  One single hole is opened to
allow programs to connect to an X server over tcp/ip running on the
host. This of course, opens a potential for snooping on keystrokes and
other X clients but this is a risk I don't know how to mitigate at the
moment.  There are apparently patches for allowing an X server to run
jailed but I'd rather wait until they're part of an official release (if
ever). I don't enable shared memory for jails.

Programs are installed into the 'untrusted' jail and invoked with a
shell script that calls "sudo jexec env -i ... $prog" with a minimal
environment ($XAUTHORITY, $DISPLAY, etc). An example would be:

  $ mistrust mplayer /tmp/test.avi

Access to /dev/dsp* inside the jail is also added with devfs rules.

I considered setting up a means of using passwordless access to sudo but
abandoned the idea because I wasn't sure about safety.

I transfer files in and out of the jail using rsync.

Jail 2 is essentially a copy of the above but as a vnode-backed image
jail to prevent a rampant program from filling up the filesystem (the
image is fixed size). This jail is solely used for Firefox. The only
connections allowed from this jail are outbound to the X server on the
host and to a single port on Jail 3.

Jail 3 is, again, an image jail copy of Jail 1. It runs a non-caching
web proxy (privoxy) and is allowed to freely use the network, except for
connecting to other jails or the host. The purpose of this jail is to
basically be the gateway to the world for Jail 2.

Jail 4 is just an area for building binary packages to distribute to
other jails. This way, installation of software in each jail is
simplified greatly. This jail is allowed to connect to the outside world
without restriction (necessary for fetching of packages).

I run portmaster to keep built binary packages up to date, jailaudit to
determine when packages need updating in other jails and pkg_replace in
each jail to actually update.

--

To be blunt, the above is essentially band-aid for a lack of strong,
granular, per-process access control to network interfaces and a lack of
a flexible per-process dynamic view of the filesystem (plan9). It works
well enough that I'm happy to use it, though.

xw