danwalsh (danwalsh) wrote,

Tug of war between SELinux and Chrome Sandbox, who's right?


Over the years, people have wanted to use SELinux to confine the web browser. The most common vulnerabilty for a desktop user is attacks caused by bugs in the browser.  A user goes to a questionable web site, and the web site has code that triggers a bug in the browser that takes over your machine.  Even if the browser has no bugs, you have to worry about helper plugins like flash-plugin, having vulnerabilities.

I wrote about confineing the browser all the way back in 2008. As I explained then, confining the browser without breaking expected functionality is impossible, but we wanted to confine the "plugins".  Luckily Mozilla and Google also wanted to confine the plugins, so they broke them into separate programs which we can wrap with SELinux labels.  By default all systems running firefox or chrome the plugins are locked down by SELinux preventing them from attacking your home dir.  But sometimes we have had bugs/conflicts in this confinement.

SELinux versus Chrome.

We have been seeing bug reports like the following for the last couple of years.

SELinux is preventing chrome-sandbox from 'write' accesses on the file oom_score_adj.

I believe the chrome-sandbox is trying to tell the kernel to pick it as a candidate to be killed if the machine gets under memory pressure, and the kernel has to pick some processes to kill.

But SELinux blocks this access generating an AVC that looks like:

type=AVC msg=audit(1426020354.763:876): avc:  denied  { write } for  pid=7673 comm="chrome-sandbox" name="oom_score_adj" dev="proc" ino=199187 scontext=unconfined_u:unconfined_r:chrome_sandbox_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=file permissive=0

This SELinux AVC indicates that the chrome-sandbox running as chrome_sandbox_t is trying to write to the oom_score_adj field in its parent process, most likely the chrome browser process, running as unconfined_t.  The only files labeled as unconfined_t on a system are virtual files in the /proc file system.

SELinux is probably blocking something that should be allowed, but ...

We have gone back and forth on how to fix this issue.

If you read the bugzilla

Scott R. Godin points out:

according to the final comment at https://bugs.chromium.org/p/chromium/issues/detail?id=477329

"Restricting further comments.

As explained in https://code.google.com/p/chromium/issues/detail?id=477329#c5 https://code.google.com/p/chromium/issues/detail?id=477329#c8 and  https://code.google.com/p/chromium/issues/detail?id=477329#c11 this is working as intended."

so, google says 'works as intended'. *cough*

https://bugzilla.redhat.com/show_bug.cgi?id=581256 (earlier discussion of this) says it's a google-chrome issue not an selinux issue.

I dunno who to believe at this point.

I respond:

I would say it is a difference of opinion.  From Google's perspective they are  just allowing the chrome-sandbox to tell the kernel to pick chrome, when looking to kill processes on the system if they run out of memory.  But from SELinux point of view it can't tell the difference between the chrome browser and other processes on the system that are labeled as unconfined_t.  From a MAC point of view, this would allow the chrome-sandbox to pick any other user process to kill if running out of memory. It is even worse then this, allowing chrome_sandbox_t to write to files labeled as unconfined_t allows the chrome-sandbox to write to file objects under /proc of almost every process in the user session.  Allowing this access would destroy the effectiveness of the SELinux confinement on the process.

If we want to control the chrome-sandbox from a MAC perspective, we don't want to allow this. 

Bottom line both sides are in some ways correct.

This is why you have a boolean and a dontaudit rule.  If you don't want MAC confinement of chrome sandbox then you can disable it using

# setsebool -P unconfined_chrome_sandbox_transition 0

Or you can ignore the problem with a dontaudit rule and the chrome-sandbox will not be able to say PICKME for killing in an out of memory situation.

There are other ways you can run confined web browsers. One of the first "Containers" was introduced way back in Fedora 12/13 RHEL6 time frame, the SELinux Sandbox. This allowed you to run a sanboxed web browser totally isolated from the desktop.  The Flatpak effort is a newer effort to run containerized Desktop Applications.
Tags: selinux security flatpak containers chro

  • Container Domains (Types)

    One of the things people have always had a hard time understanding about SELinux is around different types. In this blog, I am going to discuss…

  • Musings on Hybrid Cloud

    I work on the lowest levels of container runtimes and usually around process security. My team and I work on basically everything needed run…

  • Container Labeling

    An issue was recently raised on libpod, the github repo for Podman. "container_t isn't allowed to access container_var_lib_t" Container policy…

  • Post a new comment


    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened