Re: Sandboxing

On 09/11/06, Lowell Gilbert <freebsd-security-local@xxxxxxxxxxxxxxx> wrote:
"mal content" <artifact.one@xxxxxxxxxxxxxx> 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
_______________________________________________
freebsd-security@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Sandboxing
    ... Nobody sandboxes on FreeBSD? ... difference between an X client and an X server (only the latter has ... direct access to memory), X clients do have fairly privileged access ...
    (FreeBSD-Security)
  • Using chroot to create reproducible sandboxes
    ... Has anyone used chroot to create highly isolated ... 'sandboxes' that can be used provide reproducible envionments? ... for security purposes. ... Usually, I would handle this problem by simply Jumpstarting the machines, ...
    (SunManagers)
  • Re: Sandboxing
    ... difference between an X client and an X server (only the latter has ... direct access to memory), X clients do have fairly privileged access ... Perhaps one would use Xvnc to eliminate issues with the client mucking around in the X server space? ... It seems like while jails, vnc, and sandboxes may work, the safest method is to run in a VM as you mentioned. ...
    (FreeBSD-Security)