[Desktop-packages] [Bug 1447345] Re: Support the unprivileged namespace sandbox

2018-03-12 Thread Olivier Tilloy
** Changed in: chromium-browser (Ubuntu)
 Assignee: Chad Miller (cmiller) => (unassigned)

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to evince in Ubuntu.
https://bugs.launchpad.net/bugs/1447345

Title:
  Support the unprivileged namespace sandbox

Status in Oxide:
  Triaged
Status in chromium-browser package in Ubuntu:
  Confirmed
Status in evince package in Ubuntu:
  Confirmed

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,  
  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

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1447345] Re: Support the unprivileged namespace sandbox

2017-03-22 Thread Chris Coulson
** Changed in: oxide
Milestone: branch-1.22 => branch-1.23

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to evince in Ubuntu.
https://bugs.launchpad.net/bugs/1447345

Title:
  Support the unprivileged namespace sandbox

Status in Oxide:
  Triaged
Status in chromium-browser package in Ubuntu:
  Confirmed
Status in evince package in Ubuntu:
  Confirmed

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,  
  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

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1447345] Re: Support the unprivileged namespace sandbox

2017-02-06 Thread Chris Coulson
** Changed in: oxide
Milestone: branch-1.21 => branch-1.22

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to evince in Ubuntu.
https://bugs.launchpad.net/bugs/1447345

Title:
  Support the unprivileged namespace sandbox

Status in Oxide:
  Triaged
Status in chromium-browser package in Ubuntu:
  Confirmed
Status in evince package in Ubuntu:
  Confirmed

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,  
  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

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1447345] Re: Support the unprivileged namespace sandbox

2017-02-02 Thread Launchpad Bug Tracker
Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: evince (Ubuntu)
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to evince in Ubuntu.
https://bugs.launchpad.net/bugs/1447345

Title:
  Support the unprivileged namespace sandbox

Status in Oxide:
  Triaged
Status in chromium-browser package in Ubuntu:
  Confirmed
Status in evince package in Ubuntu:
  Confirmed

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,  
  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

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1447345] Re: Support the unprivileged namespace sandbox

2016-12-14 Thread Chris Coulson
** Changed in: oxide
Milestone: branch-1.20 => branch-1.21

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to evince in Ubuntu.
https://bugs.launchpad.net/bugs/1447345

Title:
  Support the unprivileged namespace sandbox

Status in Oxide:
  Triaged
Status in chromium-browser package in Ubuntu:
  Confirmed
Status in evince package in Ubuntu:
  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,  
  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

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1447345] Re: Support the unprivileged namespace sandbox

2016-10-28 Thread Chris Coulson
** Changed in: oxide
Milestone: branch-1.19 => branch-1.20

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to evince in Ubuntu.
https://bugs.launchpad.net/bugs/1447345

Title:
  Support the unprivileged namespace sandbox

Status in Oxide:
  Triaged
Status in chromium-browser package in Ubuntu:
  Confirmed
Status in evince package in Ubuntu:
  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,  
  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

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1447345] Re: Support the unprivileged namespace sandbox

2016-09-20 Thread Jean Christophe André
Same here with Evince not being able to lauch the browser when you clic
on a link inside a PDF:

apparmor="DENIED" operation="capable"
profile="/usr/bin/evince//sanitized_helper" pid=16137 comm="chromium-
browse" capability=21  capname="sys_admin"

** Also affects: evince (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to chromium-browser in Ubuntu.
https://bugs.launchpad.net/bugs/1447345

Title:
  Support the unprivileged namespace sandbox

Status in Oxide:
  Triaged
Status in chromium-browser package in Ubuntu:
  Confirmed
Status in evince package in Ubuntu:
  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,  
  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

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1447345] Re: Support the unprivileged namespace sandbox

2016-09-12 Thread Chris Coulson
** Changed in: oxide
Milestone: branch-1.18 => branch-1.19

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to chromium-browser in Ubuntu.
https://bugs.launchpad.net/bugs/1447345

Title:
  Support the unprivileged namespace sandbox

Status in Oxide:
  Triaged
Status in chromium-browser package in Ubuntu:
  Confirmed

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,  
  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

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1447345] Re: Support the unprivileged namespace sandbox

2016-09-06 Thread Craig
I can confirm that chromium-browser does not start, syslog shows:

apparmor="DENIED" operation="capable" profile="/usr/lib/chromium-browser
/chromium-browser" pid=27954 comm="chromium-browse" capability=21
capname="sys_admin"

Apparmor profile enforce mode.
Trusty 14.04.5
chromium-browser 51.0.2704.79
apparmor-profiles 2.8.95-2430

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to chromium-browser in Ubuntu.
https://bugs.launchpad.net/bugs/1447345

Title:
  Support the unprivileged namespace sandbox

Status in Oxide:
  Triaged
Status in chromium-browser package in Ubuntu:
  Confirmed

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,  
  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

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1447345] Re: Support the unprivileged namespace sandbox

2016-07-29 Thread Chris Coulson
** Changed in: oxide
Milestone: branch-1.17 => branch-1.18

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to chromium-browser in Ubuntu.
https://bugs.launchpad.net/bugs/1447345

Title:
  Support the unprivileged namespace sandbox

Status in Oxide:
  Triaged
Status in chromium-browser package in Ubuntu:
  Confirmed

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,  
  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

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1447345] Re: Support the unprivileged namespace sandbox

2016-06-02 Thread Chris Coulson
** Changed in: oxide
Milestone: branch-1.16 => branch-1.17

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to chromium-browser in Ubuntu.
https://bugs.launchpad.net/bugs/1447345

Title:
  Support the unprivileged namespace sandbox

Status in Oxide:
  Triaged
Status in chromium-browser package in Ubuntu:
  Confirmed

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,  
  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

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1447345] Re: Support the unprivileged namespace sandbox

2016-04-26 Thread Chris Coulson
** Changed in: oxide
Milestone: branch-1.15 => branch-1.16

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to chromium-browser in Ubuntu.
https://bugs.launchpad.net/bugs/1447345

Title:
  Support the unprivileged namespace sandbox

Status in Oxide:
  Triaged
Status in chromium-browser package in Ubuntu:
  Confirmed

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,  
  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

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1447345] Re: Support the unprivileged namespace sandbox

2016-02-28 Thread Launchpad Bug Tracker
Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: chromium-browser (Ubuntu)
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to chromium-browser in Ubuntu.
https://bugs.launchpad.net/bugs/1447345

Title:
  Support the unprivileged namespace sandbox

Status in Oxide:
  Triaged
Status in chromium-browser package in Ubuntu:
  Confirmed

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,  
  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

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1447345] Re: Support the unprivileged namespace sandbox

2016-02-28 Thread hda_launchpad
Anyway to fix this?
>apparmor="ALLOWED" operation="capable" 
>profile="/usr/lib/chromium-browser/chromium-browser" pid=2129 
>comm="chromium-browse" capability=21 capname="sys_admin"

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to chromium-browser in Ubuntu.
https://bugs.launchpad.net/bugs/1447345

Title:
  Support the unprivileged namespace sandbox

Status in Oxide:
  Triaged
Status in chromium-browser package in Ubuntu:
  Confirmed

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,  
  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

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1447345] Re: Support the unprivileged namespace sandbox

2016-02-24 Thread Chris Coulson
** Changed in: oxide
Milestone: branch-1.13 => branch-1.15

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to chromium-browser in Ubuntu.
https://bugs.launchpad.net/bugs/1447345

Title:
  Support the unprivileged namespace sandbox

Status in Oxide:
  Triaged
Status in chromium-browser package in Ubuntu:
  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,  
  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

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1447345] Re: Support the unprivileged namespace sandbox

2015-12-16 Thread Chris Coulson
** Changed in: oxide
Milestone: branch-1.12 => branch-1.13

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to chromium-browser in Ubuntu.
https://bugs.launchpad.net/bugs/1447345

Title:
  Support the unprivileged namespace sandbox

Status in Oxide:
  Triaged
Status in chromium-browser package in Ubuntu:
  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,  
  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

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1447345] Re: Support the unprivileged namespace sandbox

2015-12-14 Thread Jamie Strandboge
There have been reports that chromium-browser in Ubuntu now doesn't start under 
its apparmor profile because of:
apparmor="ALLOWED" operation="capable" 
profile="/usr/lib/chromium-browser/chromium-browser" pid=2129 
comm="chromium-browse" capability=21  capname="sys_admin"

** Also affects: chromium-browser (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to chromium-browser in Ubuntu.
https://bugs.launchpad.net/bugs/1447345

Title:
  Support the unprivileged namespace sandbox

Status in Oxide:
  Triaged
Status in chromium-browser package in Ubuntu:
  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,  
  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

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1447345] Re: Support the unprivileged namespace sandbox

2015-12-14 Thread Chad Miller
** Changed in: chromium-browser (Ubuntu)
 Assignee: (unassigned) => Chad Miller (cmiller)

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to chromium-browser in Ubuntu.
https://bugs.launchpad.net/bugs/1447345

Title:
  Support the unprivileged namespace sandbox

Status in Oxide:
  Triaged
Status in chromium-browser package in Ubuntu:
  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,  
  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

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp