• 1
chrome-sandbox is the binary that sets up the (much weaker than SELinux) chroot jail. On a real SELinux system I guess you'd want to skip it entirely and just use SELinux.

We've tried to implement some basic direct SELinux support, which is a compile-time flag. There's some code discussing it here:

My belief is that that the outer Chrome itself needs access to pretty much everything -- network, disk, etc. but without any RX pages. Then the renderer subprocess should be completely walled off from everything except for shared memory, but they need RX pages.

I started a thread on the developer list here:

I still think you need the separate process.

SELinux is all about isolating processes. SELinux allows you to run each process with a different label. The kernel governs rules about the access allowed for each labelled process. The SELinux developers prefer fork/exec to make sure there is a clean break between the processes. So no shared memory/resources could be used as a side channel to subvirt the control of the kernel. setexec functionality was added for use where applications could not make a clear separation but still wanted some control.

From a Fedora/Red Hat perspective, we do not force everyone to run with SELinux enabled. Fedora/Red Hat allow users to run their SELinux systems in three different states. Enforcing, Permissive, Disabled. So I would think the Chromium-browser, would want to provide some protection in each one of these states.

I would prefer to stick with the current separate process setting up your less secure chroot environment. And if the user has SELinux enabled in Enforcing or permissive they get additional security versus, you get good security with SELinux turned on, but nothing with SELinux disabled.

  • 1

Log in