|
LinuxSandboxing
Linux Sandboxing
Chromium uses a multiprocess model where each tab (roughly) is a separate process which performs IPCs to a UI process. This means that we can do parallel rendering and withstand crashes in the renderer. It also means that we are able to sandbox the renderers on Windows. The Chromium sandbox is an important part of keeping users safe. The web is a very complicated place these days and the code to parse and interpret it is large and on the front-line of security. We try to make sure that this code is free of security bugs, but history suggests that we can't be perfect. So, we plan for the case where someone has an exploit against our rendering code and run it in its own process with limited authority. It's the sandbox's job to limit that authority as much as possible. Chromium renderers need very little authority. They need access to fontconfig to find fonts on the system and to open those font files. However, these can be handled as IPC requests to the browser process. They do not need access to the X server (which is why we don't have GTK widgets on web pages), nor should they be able to access DBus, which is increasingly powerful these days. Drawing is handled using SysV shared memory (so that we can share memory directly with X). Everything else is either serialised over a socketpair or passed using a file descriptor to a tmpfs file. This means that we can deny filesystem access completely. The renderer requires no network access: the network stack is entirely within the browser process. The SUID sandbox(we need to readd a path restriction and remove the environment hack since we switched to 64-bit mode). This sandbox is currently used in most packages: http://src.chromium.org/viewvc/chrome/trunk/src/sandbox/linux/suid/ The seccomp sandboxCurrently building by default, but not enabled by default. http://www.imperialviolet.org/2009/08/26/seccomp.html http://lwn.net/Articles/346902/ http://src.chromium.org/viewvc/chrome/trunk/src/sandbox/linux/seccomp/ SELinuxOne can build Chromium with selinux=1 and the renderers will do a dynamic transition. audit2allow will quickly build a usable module. http://src.chromium.org/viewvc/chrome?view=rev&revision=26257 http://www.imperialviolet.org/2009/07/14/selinux.html (grep for 'dynamic' since dynamic transitions are a little obscure in SELinux) AppArmorAvailable on Ubuntu and openSUSE (XXX where else?). It triggers based on the path of the binary. We can hard link /opt/chromium.org/chromium/chrome-renderer to chrome and have different triggers for each. The configs are kept in /etc/apparmor.d and here's one which works for our renderers: #include <tunables/global>
/dev/chromium/chrome/Hammer/chrome-renderer {
#include <abstractions/base>
#include <abstractions/fonts>
/proc/** r,
/dev/shm/** rwk,
/dev/chromium/chrome/Hammer/** r,
network,
}The /dev/shm access is needed because we still have to change the visited link table to use capabilities, not names. The "network" line grants full network access, which is very unfortunate. It seems that Apparmor thinks UNIX domain sockets are AF_INET and it cannot distinguish between socket creation and use. There may be ways around this, but I suspect it'll involve kernel patches. I can do that and push upstream, but it'll take time to deploy and we have do the best we can with what we've got. If you drop this in a file in /etc/apparmor.d, then you can load the profile in enforcing mode with: # apparmor_parser -r <filename> You can also put it in 'complain' mode (where violations are logged to dmesg) with: # apparmor_parser -Cr <filename> |
I blogged about SELinux and Chrome a while back, it has some helpful information, though it would need to be expanded quite a bit: http://securityblog.org/brindle/2008/09/02/web-browsers-security-and-google-chrome/
Also, Ubuntu has both Apparmor and SELinux built in the kernel, you can only use 1 at a time, specified on the kernel command line.
To get help with SELinux sandboxing, please contact the SELinux mailing list: http://www.nsa.gov/research/selinux/list.shtml
There's also a Fedora SELinux mailing list: http://www.redhat.com/mailman/listinfo/fedora-selinux-list
Dan Walsh has been doing some work on sandboxing recently, see his blog post @: http://danwalsh.livejournal.com/28545.html
selinux is right way of doing this
Ubuntu are supposedly investigating SELinux to replace AppArmor? and openSUSE now also ships SELinux support.
SELinux has been the sandboxing technology for Linux for quite some time now.
Novell tried to re-invent the wheel with AppArmor?, but how is the state of it today? Is it still actively maintained by someone after Novell stopped development? Has it been accepted into the kernel like SELinux? I'm not sure actually but I think it still requires manual patching.
Right, both Ubuntu (for some time) and openSUSE (since 11.1) also ship SELinux, at least to some extend. Both don't enable it by default but then again, how is their support for AppArmor? by default? Ubuntu only ships AppArmor? profiles for a few selected services like CUPS and MySQL for example.
So, Fedora currently is the only Distribution shipping with a working sandbox (SELinux) enabled by default. IMHO Chrome on linux should use this and just keep the "no sandbox" option for distributions which don't see the need for it.
This would actually be fairly simple in SELinux, similar to what we have done with nsplugin. Just a matter of setting up a domain for the renderer and allowing user domains (unconfined_t) to transition to the domain.
SELinux is standard on Fedora, Red Hat Enterprise Linux, Centos, and all other distributions based on RHEL. SELinux also works on Debian, Gentoo, Ubuntu and is currently turned on in Suse, I believe.
We would be willing to work with you on SELinux and Chromium integration.
dwalsh@redhat.com