Sandboxing

[mal content]

On 09/11/06, Lowell Gilbert <freebsd-security-local at be-well.ilk.org> wrote:
> "mal content" <artifact.one at googlemail.com> 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