> 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 _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"