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.

  • 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: support.mozilla.org/en-US/questions/1111998 – mostlyinformed May 28 '16 at 19:08
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):

  • 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... – user28177 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 5 '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... – user28177 Jul 6 '17 at 10:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.