PR_SET_NO_NEW_PRIVS, unshare, and chroot

With this set, a lot of dangerous operations (chroot, unshare, etc) become a lot less dangerous because there is no possibility of subverting privileged binaries.

This patch completely breaks apparmor.  Someone who understands (and uses) apparmor should fix it or at least give me a hint.

Signed-off-by Andy Lutomirski <[email protected]>

They are normally disallowed because they could be used to subvert setuid programs.  But if setuid is disabled, then they are safe.

Signed-off-by Andy Lutomirski <[email protected]>

---
 kernel/nsproxy.c |    8 +++++++-

 1 files changed, 7 insertions(+), 1 deletions(-)

kernel/nsproxy.c +0 -1

index b576f7f..47cf873 100644
@@ -191,7 +191,13 @@ int unshare_nsproxy_namespaces(unsigned long unshare_flags,
                               CLONE_NEWNET)))
                return 0;
 
-       if (!capable(CAP_SYS_ADMIN))

Quoted 17 lines · Andy Lutomirski

They are normally disallowed because they could be used to subvert setuid programs.  But if setuid is disabled, then they are safe.

Signed-off-by Andy Lutomirski <[email protected]>

---
 kernel/nsproxy.c |    8 +++++++-

 1 files changed, 7 insertions(+), 1 deletions(-)

kernel/nsproxy.c +0 -1

index b576f7f..47cf873 100644
@@ -191,7 +191,13 @@ int unshare_nsproxy_namespaces(unsigned long unshare_flags,
                               CLONE_NEWNET)))
                return 0;
 
-       if (!capable(CAP_SYS_ADMIN))

kernel/nsproxy.c int unshare_nsproxy_namespaces(unsigned long unshare_flags, · line 203

Quoted 10 lines

kernel/nsproxy.c +7 -0

+       /* We require either no_new_privs or CAP_SYS_ADMIN for all modes */
+       if (!current->no_new_privs && !capable(CAP_SYS_ADMIN))
+               return -EPERM;
+
+       /* NEWNS and NEWNET always require CAP_SYS_ADMIN. */
+       if ((unshare_flags & (CLONE_NEWNS | CLONE_NEWNET)) &&
+           !capable(CAP_SYS_ADMIN))
                return -EPERM;
 
        *new_nsp = create_new_namespaces(unshare_flags, current,

While I think it's unlikely that the list handled by unshare_nsproxy_namespaces() is going to change, I'd still prefer that the logic of this test be reversed so that the nnp-allowed flags are listed instead of the CAP_SYS_ADMIN-required ones so that it will default to disallowing new flags. It's a little less readable, but maybe something like this (untested):

unsigned long handled_mask = (CLONE_NEWNS | CLONE_NEWUTS | CLONE_NEWIPC | CLONE_NEWNET);
unsigned long npp_mask = (CLONE_NEWUTS | CLONE_NEWIPC);

if (!(unshare_flags & handled_mask))
       return 0;

if (  !(current->no_new_privs && !(unshare_flags & (handled_mask ^ npp_mask))) && !capable(CAP_SYS_ADMIN))
       return -EPERM;
...

This also has the side-effect of removing the double-check of capable() in some cases.

Chroot can easily be used to subvert setuid programs. If no_new_privs, then setuid programs don't gain any privilege, so allow chroot.

Quoted 2 lines · Andy Lutomirski

Chroot can easily be used to subvert setuid programs.  If no_new_privs, then setuid programs don't gain any privilege, so allow chroot.

Is this needed/desired by anyone now, or are you just using it to "demo" NO_NEW_PRIVS?  I don't see it as very useful on its own, since in any "container"-type chroot you really want /proc and /dev, and your patch doesn't help with that.

System daemons that do chroot for a modicum of security already start privileged, so this doesn't help them either.

Quoted 8 lines · Colin Walters

Quoted 2 lines · Andy Lutomirski

Chroot can easily be used to subvert setuid programs. If no_new_privs, then setuid programs don't gain any privilege, so allow chroot.

Is this needed/desired by anyone now, or are you just using it to "demo" NO_NEW_PRIVS? I don't see it as very useful on its own, since in any "container"-type chroot you really want /proc and /dev, and your patch doesn't help with that.

It's a demo, but it could still be useful for container-ish things. If something privileged sets up /proc, /sys, and /dev, then unprivileged code can chroot into the container. This would allow much simpler implementations of tools like schroot.

With this change, they wouldn't need to start privileged. (Admittedly, this isn't a great argument for this patch.)

Quoted 10 lines · Andy Lutomirski

Quoted 8 lines · Colin Walters

Quoted 2 lines · Andy Lutomirski

Chroot can easily be used to subvert setuid programs.  If no_new_privs, then setuid programs don't gain any privilege, so allow chroot.

Is this needed/desired by anyone now, or are you just using it to "demo" NO_NEW_PRIVS?  I don't see it as very useful on its own, since in any "container"-type chroot you really want /proc and /dev, and your patch doesn't help with that.

Quoted 4 lines

It's a demo, but it could still be useful for container-ish things. If something privileged sets up /proc, /sys, and /dev, then unprivileged code can chroot into the container.  This would allow much simpler implementations of tools like schroot.

What's the win if you still need a setuid binary?  schroot (and my linux-user chroot binary) can just as easily call chroot as they can create bind mounts; I'm not buying a code complexity argument.

You don't need a setuid binary. Just have an initscript set up the bind mounts.

Quoted 1 line · Andy Lutomirski

You don't need a setuid binary.  Just have an initscript set up the bind mounts.

The point is that dchroot is already setuid root, and calls chroot, so it gains nothing from the ability to do it unprivileged.

(And wow, I just looked at the source, it's a setuid C++ binary!  Using boost.  Ugh...)

You can accomplish the same thing *without a scary setuid binary*. The use case doesn't even need a new complicated userspace tool. You would set up an initscript or some /etc/fstab entries and then:

no_new_privs chroot /var/chroot/ubuntu_oneiric/ /bin/bash

et voila. (Where no_new_privs would be a really simple tool that does PR_SET_NO_NEW_PRIVS and then execs its argument.)

Maybe it's just me, but I think this is useful and I would, in fact, use it in my regular workflow.

Quoted 3 lines · Andy Lutomirski

You can accomplish the same thing *without a scary setuid binary*. The use case doesn't even need a new complicated userspace tool.  You would set up an initscript or some /etc/fstab entries and then:

That requires administrative access to the system and custom configuration; if you have that, you could just as easily set up a wrapper script to run sudo + shell script to do whatever you want for example.

That's the role schroot fills now - basically pre-canned scripts, but you don't get out of custom configuration or needing root access to set it up.   And as I mentioned in https://lkml.org/lkml/2011/12/9/213, it's not as interesting as you might think even in the model of "pre-configure, give out access to regular users", because if you allow uploading .debs, it's just an elaborate root shell.

The most interesting thing to me is an entire setup that doesn't require administrative access, so you can do it on any server or workstation, and I have that with linux-user-chroot.

Quoted 2 lines

no_new_privs chroot /var/chroot/ubuntu_oneiric/ /bin/bash

Quoted 5 lines

et voila.  (Where no_new_privs would be a really simple tool that does PR_SET_NO_NEW_PRIVS and then execs its argument.)

Maybe it's just me, but I think this is useful and I would, in fact, use it in my regular workflow.

workflow for what?  Building software?  Let's try to narrow down the problem we're solving here.

Quoted 2 lines · Andy Lutomirski

Chroot can easily be used to subvert setuid programs. If no_new_privs, then setuid programs don't gain any privilege, so allow chroot.

Is this needed/desired by anyone now, or are you just using it to "demo" NO_NEW_PRIVS? I don't see it as very useful on its own, since in any "container"-type chroot you really want /proc and /dev, and your patch doesn't help with that.

System daemons that do chroot for a modicum of security already start privileged, so this doesn't help them either.

Quoted 9 lines · Colin Walters

Quoted 2 lines · Andy Lutomirski

Chroot can easily be used to subvert setuid programs.  If no_new_privs, then setuid programs don't gain any privilege, so allow chroot.

Is this needed/desired by anyone now, or are you just using it to "demo" NO_NEW_PRIVS?  I don't see it as very useful on its own, since in any "container"-type chroot you really want /proc and /dev, and your patch doesn't help with that.

Quoted 2 lines

System daemons that do chroot for a modicum of security already start privileged, so this doesn't help them either.

I thought this was all for sandboxing? If a browers (or user) wants to run some untrusted code, perhaps a chroot is the best way to do so. It just will break if it needs to access /proc or /dev. And perhaps we don't want untrusted code accessing /proc and /dev.

Quoted 9 lines · Colin Walters

Quoted 2 lines · Andy Lutomirski

Chroot can easily be used to subvert setuid programs.  If no_new_privs, then setuid programs don't gain any privilege, so allow chroot.

Is this needed/desired by anyone now, or are you just using it to "demo" NO_NEW_PRIVS?  I don't see it as very useful on its own, since in any "container"-type chroot you really want /proc and /dev, and your patch doesn't help with that.

Quoted 2 lines

System daemons that do chroot for a modicum of security already start privileged, so this doesn't help them either.

I thought this was all for sandboxing? If a browers (or user) wants to run some untrusted code, perhaps a chroot is the best way to do so. It just will break if it needs to access /proc or /dev. And perhaps we don't want untrusted code accessing /proc and /dev.

Quoted 10 lines · Steven Rostedt

Quoted 9 lines · Colin Walters

Quoted 2 lines · Andy Lutomirski

Chroot can easily be used to subvert setuid programs. If no_new_privs, then setuid programs don't gain any privilege, so allow chroot.

Is this needed/desired by anyone now, or are you just using it to "demo" NO_NEW_PRIVS? I don't see it as very useful on its own, since in any "container"-type chroot you really want /proc and /dev, and your patch doesn't help with that.

Quoted 6 lines

Quoted 2 lines

System daemons that do chroot for a modicum of security already start privileged, so this doesn't help them either.

I thought this was all for sandboxing? If a browers (or user) wants to run some untrusted code, perhaps a chroot is the best way to do so. It just will break if it needs to access /proc or /dev.

Interestingly, I believe this change would work for the Chromium setuid sandbox[1]. It uses a fancy clone trick (CLONE_FS) to start the process then chroot once all its dependencies are loaded. It then chroot()s to /proc/self/fd_info (or another empty process-specific directory).

Quoted 10 lines · Steven Rostedt

Quoted 9 lines · Colin Walters

Quoted 2 lines · Andy Lutomirski

Chroot can easily be used to subvert setuid programs.  If no_new_privs, then setuid programs don't gain any privilege, so allow chroot.

Is this needed/desired by anyone now, or are you just using it to "demo" NO_NEW_PRIVS?  I don't see it as very useful on its own, since in any "container"-type chroot you really want /proc and /dev, and your patch doesn't help with that.

Quoted 7 lines

Quoted 2 lines

System daemons that do chroot for a modicum of security already start privileged, so this doesn't help them either.

I thought this was all for sandboxing? If a browers (or user) wants to run some untrusted code, perhaps a chroot is the best way to do so. It just will break if it needs to access /proc or /dev. And perhaps we don't want untrusted code accessing /proc and /dev.

Interestingly, I believe this change would work for the Chromium setuid sandbox[1]. It uses a fancy clone trick (CLONE_FS) to start the process then chroot once all its dependencies are loaded. It then chroot()s to /proc/self/fd_info (or another empty process-specific directory).  Of course, pid namespacing still wouldn't be there, but it'd be nice to have a fallback if someone doesn't want the sandboxing setup code to have privileges (or can only install unpriv'd code).

cheers!
will
1 - http://code.google.com/p/setuid-sandbox/source/browse/privdrop.c

That's neat! CLONE_NEWPID might be safe with no_new_privs, too. Unprivileged CLONE_NEWPID would also be a nice, straightforward way to start up a process hierarchy and then reliably kill the whole thing when you're done with it.