I don't really have any insight to offer here, just a question: is there a basic write up somewhere of how this is done in Windows? I'm not at all a Windows developer, so the Chromium source code is pretty heavy reading for me, but I'd be interested in understanding how it works at a higher level if that's even possible.
Another thing that is intrieging to me is that Chrome apparently runs under Wine, so presumably Wine is providing whatever APIs Chrome is calling into under Windows. Is Wine just presenting a façade that makes Chrome think it's more sandboxed than it is, or is Wine doing something clever? (I also see several folks saying that Chrome runs really slowly under Wine, so I guess it could be doing one of the things that are listed in that article as possible but really slow. *shrug*)
That's really interesting. Thanks. I always forget that NT actually has comprehensive security mechanisms built in that are more than just "what user is this?". The use of extra desktops is interesting too, but seems like an obvious choice in retrospect once you remember that this is how Windows itself prevents apps from tampering with the "security" desktop.
As far as Wine goes, it looks like you're right. Here's an example of what most of these functions end up looking like in the Wine source code:
I guess few enough apps actually use this stuff that doing nothing is fine. Apps just pass pointers to random nonsense as security descriptors and all of Wine's functions just say "Sure! Whatever!". Worrying, but not entirely surprising.
The docs you link to sound very similar to Niels' Privilege Separation work in OpenSSH. Unfortunately privsep is too heavyweight for Chromium; it uses a user account per separation domain, and requires root to start up.
Niels also did Systrace (see also), which is slightly different but should be able to implement the sandboxing necessary.
It would be possible to have a root helper spawn new privsep domains without requiring kernel changes on Linux.
In particular, I think VServers are interesting here because unlike Xen et al, they emulate at the OS layer, not the hardware layer.
Indeed, they feel like super-fancy chroot + resource containers. I'm still poking through the docs, but I think you just start up a little plugin launcher as "init" for your "vserver" and share access to the network stack and filesystem since everything is running on the same kernel...
I was surprised how much Adam knew about this topic when I talked with him a few months ago!
ptrace is what I use for codepad.org. As Adam points out, it's slow, and things get complicated if you want to support threading. I've been thinking about hacking up the implementation of Seccomp in the kernel to support more of what I need, but for Chromium that would probably not be viable unless those changes made their way into stock kernels (and maybe they should -- it would be neat for Linux to have something like Mac OS X's new sandbox.h stuff).
I'm not aware of other options, but I would love to hear about any ideas. Is there a Google-external Chromium development list somewhere that I should be reading?