6

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.

Anders
  • 64,406
  • 24
  • 178
  • 215
Eloy Roldán Paredes
  • 1,507
  • 12
  • 25
  • Minor quibble: Firefox on Windows doesn't currently use any robust sandboxing by default. (One is now in development; see link.) Which is why I hold to the stance of telling clients to use Chrome or Edge on Windows boxes. Firefox can sometimes still be acceptable (IMHO), but only with NoScript or similar security plugin/s in place and well-configured. Mozilla link: https://support.mozilla.org/en-US/questions/1111998 – mostlyinformed May 28 '16 at 19:08

1 Answers1

11

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 ~/.config drive 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 file command 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

    • /etc/shadow

    • ~/.ssh

    • ~/secret/DansPlanForWorldDomination.odp

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):

Community
  • 1
  • Well, I'll be damned if these aren't excellent examples. I think it would be valuable though to explain that SELinux will not and should not prevent Chrome from accessing the majority of users' documents, as this is an expected feature for file uploads. This is a common misconception that some people who reach this question in the future will have. – Steve Dodier-Lazaro May 27 '16 at 20:03
  • 1
    Thanks for the comment @SteveDL. I have added a new topic based on your feedback :) - And also, take a look at the bug where chromium tries to grep `/etc/passwd`. That is weid... –  May 27 '16 at 20:36
  • 1
    interestingly I got into SELinux when I saw that Acroread read /etc/passwd. At the time the recommended way of running permissive and using audit2allow would produce a policy that allowed it by default. That really goes on to show why securing a whole desktop with SELinux is *not* fun. – Steve Dodier-Lazaro May 28 '16 at 10:17
  • @nwildner - just to clarify possible confusion: `/etc/passwd` contains username - UID mapping, group, and default shell. It does not contain any sensitive information whatsoever. – Martin Vegter Jul 05 '17 at 22:15
  • 1
    Oh, i know. And I disagree that it should be allowed if no sensitive information is there. Also, the correct way to achieve this info is using `getpw*() getgr*()` functions as explained on that issue. No need to access `/etc/passwd` directly... –  Jul 06 '17 at 10:43
  • -1 While this is a well-thought-out answer, the fact is that it does not just protect from issues created _by_ Chrome, in fact I would say that that is an extreme minority of bugs it protects against. The real purpose is to protect from sandbox escapes (which are not too uncommon), limiting what a fully compromised browser can do. – forest Jan 20 '18 at 11:41
  • You disagree that the bugs enlisted above were created by Chrome? To me, escaping sandbox is a Chrome bug as much as escaping Chrome domain and i have listed only THOSE sandbox related bugs cause that is why the question is about(and thus, the low number of specific bugs). The question is about how SELinux could give additional protection to Chrome Sandboxing (means: Isn't sandbox enough? - short answer:No) and you seem to miss the whole point. Thanks for your feedback anyway :) –  Jan 20 '18 at 16:25