Chromium

The setuid sandbox has to go:

- For each "chroot me" event, the current mechanism requires having previously started a setuid helper. This is not compatible with a more generic and universal Zygote. It is in conflict with the flexibility we want for Mojo.
- chroot helpers are tied to new PID and network namespaces. Again, this conflicts with flexibility as network namespaces use a lot of kernel memory.
- Shipping a setuid binary on Linux and on Chrome OS is bad for security.
- Having to update a setuid executable on our bots when we want to make changes is problematic

Hopefully we can fix the following issues as well:
- To be isolated from each other, renderers need to be marked as non dumpable. Since Breakpad needs to be able to ptrace() renderers, they become dumpable again on SIGSEGV.
To prevent a renderer from sending SIGSEGV to another renderer, we put in place an authentication mechanism which require a kernel fix (CVE-2011-1182). This fix has now regressed. Also see https://crbug.com/chromium/169369.

Both seccomp-bpf and Yama can offer an alternate way to protect processes in the same PID namespace from each other.

- Searching for the "real pid" of children under a new PID namespace is tremendously complicated and requires going through each process in /proc (which is itself much harder when the processes are not dumpable). We should investigate the cost of having one PID namespace per process as it would allow the parent to immediately know the real PID. It would also solve the "dumpable" issue neatly as processes wouldn't need to be non dumpable.

Plans:

- Use unprivileged namespaces (through CLONE_NEWUSER) when available. Hopefully this will be available by default with Ubuntu 14.04 LTS.
I have made a proof-of-concept and it looks like it'll work.
With unprivileged namespaces processes could keep the CAP_SYS_CHROOT capability until the sandbox is fully engaged, which would solve a lot of the current issues.

- Get CLONE_NEWUSER in Chrome OS with kernel 3.9+

- Link Chromium against libcap2. If that's not possible, rewrite a small POSIX.1e library.

- We may have to support the current setuid sandbox mechanism alongside the new mechanism until support for Ubuntu Precise is dropped. It's unfortunate as complexity is high.