← Back to team overview

ubuntu-webapps-bugs team mailing list archive

[Bug 1447345] [NEW] Support the unprivileged namespace sandbox

 

Public bug reported:

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)

** Affects: oxide
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Ubuntu
WebApps bug tracking, which is subscribed to Oxide.
https://bugs.launchpad.net/bugs/1447345

Title:
  Support the unprivileged namespace sandbox

Status in Oxide Webview:
  New

Bug description:
  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)

To manage notifications about this bug go to:
https://bugs.launchpad.net/oxide/+bug/1447345/+subscriptions


Follow ups

References