I disabled selinux support in chromium as I couldn't get it to work at all (regardless of policy). By switching back to the "regular" mode, I know I can now update the policy to make it supported.
I opt for this method instead of the "build-in SELinux support" as, from what I read on the Internet, the SELinux-support in chromium is actually /not/ supported (just provided as-is).
I'll leave in the chromium_renderer_t support in the policy, but will try to get the regular installation confined as well (with the standard zygote sandbox).
LaunchProcess: failed to execvp:
In the denial logs, we notice that chrome_sandbox is not labeled correctly. Labeling it as bin_t yields:
Failed to move to new PID namespace: Operation not permitted
In the AVC denials, it shows that we need sys_admin capability. okay...
Setting RLIMIT_NOFILE: Permission denied
[1:1:0411/203220:ERROR:setuid_sandbox_client.cc(124)] Failed to write to chroot pipe: Broken pipe
[1:1:0411/203220:FATAL:zygote_main_linux.cc(479)] Failed to enter sandbox. Fail safe abort. (errno: 32)
Now needs setuid/setgit and a couple of other. However, I'm now taking a step back and will create a chromium_sandbox_t domain for the chrome_sandbox binary. Don't feel too good to grant the entire chromium_t domain those privileges if I can isolate it.
I just pushed out the necessary changes to get things to work. It provides two additional SELinux domains, one for the sandbox and one for the nacl_helper.
I've found a workaround: launch chromium with --no-sandbox.
Given that it's confined by SELinux, it's not as bad as it may sound. Still, I'd like to fix the underlying cause, but the above gives some clue about what is happening.
01 May 2013; Pawel Hajdan jr
Disable unmaintained upstream SELinux mode, bug #465574 by swift, bug #467954
by Dominik Kriegner.
In main tree, ~arch'ed (20130424-r1 release)
Now stable in repo