Chromium has a new layer 1 sandbox which replaces the suid sandbox on systems with CLONE_NEWUSER. However, it's currently incompatible with application confinement.
To summarize, the sandbox mechanism does something like this:
1) Browser launches zygote process:
- clones with CLONE_NEWUSER | CLONE_NEWPID | CLONE_NEWNET and then exec()
2) Zygote initializes sandbox:
- unshare(CLONE_NEWUSER)
- clones a new process with CLONE_FS and then does waitpid(). The child chroots to /proc/self/fdinfo
- Enables CAP_SYS_ADMIN (see below)
3) Zygote forks
- Parent becomes init
- Child continues as zygote
4) Zygote waits for requests from the browser to create render processes
5) On each request:
- Zygote clones a new process with CLONE_NEWPID (this is why it needs CAP_SYS_ADMIN)
- New process drops all privileges and becomes a renderer
This produces the following denial on the device:
type=1400 audit(1429733985.487:153): apparmor="DENIED" operation="capable" profile="com.zeptolab.cuttherope.full_cuttherope_0.5.2" pid=7195 comm="qmlscene" capability=21 capname="sys_admin"
The oxide_helper profile already allows sys_admin, but this is coming from the browser process, just here:
7229 clone(child_stack=0, flags=CLONE_NEWUSER|SIGCHLD) = 7246 <-- Test that the new sandbox can be used
7246 exit_group(0) = ?
7229 wait4(7246, <unfinished ...>
7246 +++ exited with 0 +++
7229 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 7246
7229 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=7246, si_status=0, si_utime=0, si_stime=0} ---
7229 write(13, "\0", 1) = 1
7229 rt_sigreturn() = 7246
7229 access("/proc/self/ns/user", F_OK) = 0
7229 access("/proc/self/ns/user", F_OK) = 0
7229 access("/proc/self/ns/pid", F_OK) = 0
7229 access("/proc/self/ns/user", F_OK) = 0
7229 access("/proc/self/ns/net", F_OK) = 0
7229 getuid32() = 32011
7229 getgid32() = 32011
7229 access("/proc/self/setgroups", F_OK) = -1 ENOENT (No such file or directory)
7229 rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0
7229 clone(child_stack=0xbe8518d4, flags=CLONE_NEWUSER|CLONE_NEWPID|CLONE_NEWNET|SIGCHLD) = -1 EPERM (Operation not permitted)
It fails in step 1) above, because it needs CAP_SYS_ADMIN before it's able to transition to the oxide_helper profile (which allows it)
I've done some testing with a little test program and basic AppArmor confinement. When an unconfined and unprivileged process enters a new user and pid namespace, it picks up all capabilities. When a confined and unprivileged process enters a new user and pid namespace, it only picks up the capabilities that are listed in the AppArmor profile.