On 09/11/06, Lowell Gilbert <[EMAIL PROTECTED]> wrote:
"mal content" <[EMAIL PROTECTED]> writes:
> So, uh, is that it?
>
> Nobody sandboxes on FreeBSD?
Right. The Handbook and FAQ discussions of sandboxes are strictly
there as practical jokes.
Damn. They caught me out.
Seriously, though, while Erik Trulsson was correct in pointing out the
difference between an X client and an X server (only the latter has
direct access to memory), X clients do have fairly privileged access
to the server, and I don't have a lot of confidence in the safety of a
sandboxed application running in a normal X session. It's certainly
possible, though; jail(8) and chroot(8) are the obvious places to
start. As I think I mentioned earlier, I use qemu VMs to do something
similar, although in my case the main point is to start the
application from an *identical* configuration every time.
I think to really sandbox this program, there are going to have to be
changes to the source. I don't really like the idea of creating a filesystem
tree for all of Firefox's dependencies.
It's that .mozilla directory that causes the headaches.
My ideal situation would be:
1. Execute firefox binary under strict resource limits (coredumpsize = 0,
memoryuse/datasize = 96000). Ideally some sort of openfiles limit would
be nice. Firefox is currently using an amazing number of filedescriptors
for what it does:
$ fstat | grep firefox | wc -l
190
Now this is the tricky bit:
2. Chroot to /tmp.
3. Drop privileges and connect to X server.
I don't think it will be possible to connect to the X server when chrooted
in /tmp, due to the reliance on various ~/.x* files. Obviously, it's
not possible
to chroot without root privileges, so it seems to be mutually exclusive.
The trouble with running a complex application (like a web browser) in
a chroot or jail is that it has a long chain of other files it needs
to access at runtime. Putting all of those inside its captive
directory tree will be quite a bit of work.
Yeah, I'm quite painfully aware of the complexity of browsers. Nasty
pieces of work (although it's arguably not their fault).
Server daemons are a different story; many of them are designed to
work well in a limited environment, and doing so is quite easy. In
fact, named(8) seems to do that by default on FreeBSD these days.
Be well.
And yourself!
MC
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
