Date: Thu, 9 Nov 2006 15:32:19 +0000 From: "mal content" <artifact.one@googlemail.com> To: freebsd-security-local@be-well.ilk.org Cc: freebsd-security@freebsd.org Subject: Re: Sandboxing Message-ID: <8e96a0b90611090732j78a34d96t16119eba0cdaabc4@mail.gmail.com> In-Reply-To: <44slgs3cdy.fsf@be-well.ilk.org> References: <8e96a0b90611080439n558022edj79febf458494ef6e@mail.gmail.com> <8e96a0b90611080441t2b486637ya10acd5a1dd77690@mail.gmail.com> <44irhq6ngd.fsf@be-well.ilk.org> <20061108142306.GA64711@owl.midgard.homeip.net> <8e96a0b90611082359jbc85b37kad6109a0aa87598@mail.gmail.com> <44slgs3cdy.fsf@be-well.ilk.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 09/11/06, Lowell Gilbert <freebsd-security-local@be-well.ilk.org> wrote: > "mal content" <artifact.one@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8e96a0b90611090732j78a34d96t16119eba0cdaabc4>