Chrome on Windows and Linux and Firefox on Windows are executed in a sandbox. On Linux, is the Chrome sandbox enough or would we gain security if we use SELinux to protect the Chrome execution? I would like to avoid SELinux due to its complexity if it does not improve security.
SELinux will protect you against bugs created BY the chromium community, and their "oopses" or "hidden features" of that browser. You cannot put all eggs in one basket when it comes to security. Here, some examples where disabling selinux could not be a good idea:
- SELinux is preventing chrome-sandbox from write access on the file oom_score_adj - A regression that Chromium developers try to blame selinux when it's their fault. It was introduced on an update and Chromium was trying to manipulate Out-Of-Memory. Clearly, it will get denied by any MAC system, cause it's pretty obvious that is not "cool" to list itself as a process to not be killer in a OOM scenario.
- SELinux is preventing /opt/google/chrome/chrome-sandbox "write" access on oom_adj - In this case, a leaked file descriptor would prevent Chromium being killed on OOM cases. Clearly, a bug that would affect any system without SELinux. A regression/"hidden feature" that was blocked by SELinux.
- "Aw, Snap!" in openDatabase (e.g. while loading Twitter) in Fedora 15 with SELinux enforcing enabled: Some sites were crashing when a Chromium render passes file descriptors to chromium-sandbox. A misconception on file labels that could be fixed with
restorecon -R ~/.configdrive chromium to crash while rendering some sites. Clearly, a bug on chromium that SELinux prevented possible damages. If you take a time to read the comments, you will notice that some developers don't even know why it's crashing, and other rush into saying "disable SELinux". Not cool...
- Fedora SELinux problems with launching Chrome: Launching chromium without sandbox (
google-chrome --no-sandbox) works, while with sandbox after upgrading to version "14.0.803.0 dev" don't. Chromium added ASLR at compilation time, but SELinux was blocking text-relocations. SELinux does not have a crystal ball to guess that Chromium binaries are being probed as libraries by the
filecommand after the browser added this security feature, and it was it's duty to block this kind of behavior. Chromium was trying to improve security, but forgot that those text relocations are indeed vectors of attack by libraries that are bad coded.
- The best: SELinux prevents google-chrome from reading the /etc/passwd file: No need to explain here. Why the damn browser would want to read your passwd file? No consistent explanation was given by chromium developers about the issue. Proof here.
SELinux does, in fact improves security and creates another layer to protect you from broken features introduced on Chromium upgrades.
What the default policy should block?
I'll quote Dan Walsh on its livejournal, where he explains the basics of the Chrome Policy. This is an explanation that was given at the date this policy was concieved, and basically:
SELinux prevents chrome-sandbox from:
Using the network
It can not copy files up to the internet
It can not send email and become a spam bot.
Writing anywhere on my home directory. Or pretty much anywhere on the system
Reading most locations on my system
Like mysql_db_t where I could have critical system data
Enforcing the least privilege, and anything that is not allowed will be blocked. So, anytime chromium implements something new that colides with the default policies(and remember, SELinux policies are OLDER that you browser), it will get an AVC.
And this is not being bad with Chromium. This is the default behavior among any software that is confined by SELinux policies.
Related Links(additional docs):