Requirements for CAP_SYS_ADMIN on setns() ?

Requirements for CAP_SYS_ADMIN on setns() ?

[Daniel P. Berrange]

IIUC, currently, in order to be able to invoke setns() the calling
process is required to have CAP_SYS_ADMIN capability. Alternatively
with user namespaces, access is allowed if the process' effective
uid matches the uid of the owner of the namespace.

I have a scenario though that isn't dealt with by those rules. I have
a container that was spawned by uid == 0, and I have an unprivileged
process uid != 0 in the initial namespace that I wish to allow to enter
the namespaces associated with the container.

With the CAP_SYS_ADMIN rule on setns(), it seems that the unprivileged
process will need to execute some setuid binary in order to gain the
CAP_SYS_ADMIN capability required to call setns().

Of course you can't call setns() without first obtaining a file
descriptor corresponding to the /proc/$CONTAINERPID/ns/XXXX namespace
you wish to join. This appears to require elevated privileges too.

Is it not sufficient to rely on the permissions on the /proc/$PID/ns/XXX
file to control access to a namespace, and thus allow setns() without
a CAP_SYS_ADMIN check ?   ie setns() is basically useless unless you
already have sufficient privileges to get a file descriptor for the
namespace, so why does setns need an additional privilege check beyond
that done at time of open() on the proc file.

In my scenario this would allow for a privileged daemon to open the
/proc/$PID/ns/XXX file, and then pass the file descriptor back to the
unprivileged process using SCM_RIGHTS, which could then invoke setns().
This kind of privilege separation is perferrable to requiring the
unprivileged process to run some kind of setuid program to gain the
CAP_SYS_ADMIN capability.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Re: Requirements for CAP_SYS_ADMIN on setns() ?

[Serge Hallyn]

Quoting Daniel P. Berrange (berrange-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org):
> IIUC, currently, in order to be able to invoke setns() the calling
> process is required to have CAP_SYS_ADMIN capability. Alternatively
> with user namespaces, access is allowed if the process' effective
> uid matches the uid of the owner of the namespace.
> 
> I have a scenario though that isn't dealt with by those rules. I have
> a container that was spawned by uid == 0, and I have an unprivileged
> process uid != 0 in the initial namespace that I wish to allow to enter
> the namespaces associated with the container.
> 
> With the CAP_SYS_ADMIN rule on setns(), it seems that the unprivileged
> process will need to execute some setuid binary in order to gain the
> CAP_SYS_ADMIN capability required to call setns().
> 
> Of course you can't call setns() without first obtaining a file
> descriptor corresponding to the /proc/$CONTAINERPID/ns/XXXX namespace
> you wish to join. This appears to require elevated privileges too.
> 
> Is it not sufficient to rely on the permissions on the /proc/$PID/ns/XXX
> file to control access to a namespace, and thus allow setns() without
> a CAP_SYS_ADMIN check ?   ie setns() is basically useless unless you
> already have sufficient privileges to get a file descriptor for the
> namespace, so why does setns need an additional privilege check beyond
> that done at time of open() on the proc file.
> 
> In my scenario this would allow for a privileged daemon to open the
> /proc/$PID/ns/XXX file, and then pass the file descriptor back to the
> unprivileged process using SCM_RIGHTS, which could then invoke setns().
> This kind of privilege separation is perferrable to requiring the
> unprivileged process to run some kind of setuid program to gain the
> CAP_SYS_ADMIN capability.
> 
> Regards,
> Daniel

Hey Daniel,

it's possible that as things settle down we can find ways to relax this,
but note that this behavior was very specifically added by the commit
below.  Very unfortunate that this is a feature regression over the
CONFIG_USER_NS=n case :(

5e4a08476b50fa39210fca82e03325cc46b9c235
Author: Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
Date:   Fri Dec 14 07:55:36 2012 -0800

    userns: Require CAP_SYS_ADMIN for most uses of setns.
    
    Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> found a nasty little bug in
    the permissions of setns.  With unprivileged user namespaces it
    became possible to create new namespaces without privilege.
    
    However the setns calls were relaxed to only require CAP_SYS_ADMIN in
    the user nameapce of the targed namespace.
    
    Which made the following nasty sequence possible.
    
    pid = clone(CLONE_NEWUSER | CLONE_NEWNS);
    if (pid == 0) { /* child */
        system("mount --bind /home/me/passwd /etc/passwd");
    }
    else if (pid != 0) { /* parent */
        char path[PATH_MAX];
        snprintf(path, sizeof(path), "/proc/%u/ns/mnt");
        fd = open(path, O_RDONLY);
        setns(fd, 0);
        system("su -");
    }
    
    Prevent this possibility by requiring CAP_SYS_ADMIN
    in the current user namespace when joing all but the user namespace.

Re: Requirements for CAP_SYS_ADMIN on setns() ?

[Eric W. Biederman]

Serge Hallyn <serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org> writes:

> Quoting Daniel P. Berrange (berrange-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org):
>> IIUC, currently, in order to be able to invoke setns() the calling
>> process is required to have CAP_SYS_ADMIN capability. Alternatively
>> with user namespaces, access is allowed if the process' effective
>> uid matches the uid of the owner of the namespace.
>> 
>> I have a scenario though that isn't dealt with by those rules. I have
>> a container that was spawned by uid == 0, and I have an unprivileged
>> process uid != 0 in the initial namespace that I wish to allow to enter
>> the namespaces associated with the container.
>> 
>> With the CAP_SYS_ADMIN rule on setns(), it seems that the unprivileged
>> process will need to execute some setuid binary in order to gain the
>> CAP_SYS_ADMIN capability required to call setns().
>> 
>> Of course you can't call setns() without first obtaining a file
>> descriptor corresponding to the /proc/$CONTAINERPID/ns/XXXX namespace
>> you wish to join. This appears to require elevated privileges too.
>> 
>> Is it not sufficient to rely on the permissions on the /proc/$PID/ns/XXX
>> file to control access to a namespace, and thus allow setns() without
>> a CAP_SYS_ADMIN check ?   ie setns() is basically useless unless you
>> already have sufficient privileges to get a file descriptor for the
>> namespace, so why does setns need an additional privilege check beyond
>> that done at time of open() on the proc file.
>> 
>> In my scenario this would allow for a privileged daemon to open the
>> /proc/$PID/ns/XXX file, and then pass the file descriptor back to the
>> unprivileged process using SCM_RIGHTS, which could then invoke setns().
>> This kind of privilege separation is perferrable to requiring the
>> unprivileged process to run some kind of setuid program to gain the
>> CAP_SYS_ADMIN capability.
>> 
>> Regards,
>> Daniel
>
> Hey Daniel,
>
> it's possible that as things settle down we can find ways to relax this,
> but note that this behavior was very specifically added by the commit
> below.  Very unfortunate that this is a feature regression over the
> CONFIG_USER_NS=n case :(

No this is not a feature regression over the CONFIG_USER_NS=n case.  The
patch was a setns bug fix. The situation Daniel wants to use is
exploitable.

Allowing an unprivileged user to call setns allows confusing suid root
processes.

It is completely possible for Daniels situation to work of the
unprivileged user calls setns first.  That is allowed.

Eric

Re: Requirements for CAP_SYS_ADMIN on setns() ?

[Serge E. Hallyn]

Quoting Eric W. Biederman (ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org):
> Serge Hallyn <serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org> writes:
> 
> > Quoting Daniel P. Berrange (berrange-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org):
> >> IIUC, currently, in order to be able to invoke setns() the calling
> >> process is required to have CAP_SYS_ADMIN capability. Alternatively
> >> with user namespaces, access is allowed if the process' effective
> >> uid matches the uid of the owner of the namespace.
> >> 
> >> I have a scenario though that isn't dealt with by those rules. I have
> >> a container that was spawned by uid == 0, and I have an unprivileged
> >> process uid != 0 in the initial namespace that I wish to allow to enter
> >> the namespaces associated with the container.
> >> 
> >> With the CAP_SYS_ADMIN rule on setns(), it seems that the unprivileged
> >> process will need to execute some setuid binary in order to gain the
> >> CAP_SYS_ADMIN capability required to call setns().
> >> 
> >> Of course you can't call setns() without first obtaining a file
> >> descriptor corresponding to the /proc/$CONTAINERPID/ns/XXXX namespace
> >> you wish to join. This appears to require elevated privileges too.
> >> 
> >> Is it not sufficient to rely on the permissions on the /proc/$PID/ns/XXX
> >> file to control access to a namespace, and thus allow setns() without
> >> a CAP_SYS_ADMIN check ?   ie setns() is basically useless unless you
> >> already have sufficient privileges to get a file descriptor for the
> >> namespace, so why does setns need an additional privilege check beyond
> >> that done at time of open() on the proc file.
> >> 
> >> In my scenario this would allow for a privileged daemon to open the
> >> /proc/$PID/ns/XXX file, and then pass the file descriptor back to the
> >> unprivileged process using SCM_RIGHTS, which could then invoke setns().
> >> This kind of privilege separation is perferrable to requiring the
> >> unprivileged process to run some kind of setuid program to gain the
> >> CAP_SYS_ADMIN capability.
> >> 
> >> Regards,
> >> Daniel
> >
> > Hey Daniel,
> >
> > it's possible that as things settle down we can find ways to relax this,
> > but note that this behavior was very specifically added by the commit
> > below.  Very unfortunate that this is a feature regression over the
> > CONFIG_USER_NS=n case :(
> 
> No this is not a feature regression over the CONFIG_USER_NS=n case.  The
> patch was a setns bug fix. The situation Daniel wants to use is
> exploitable.
> 
> Allowing an unprivileged user to call setns allows confusing suid root
> processes.
> 
> It is completely possible for Daniels situation to work of the
> unprivileged user calls setns first.  That is allowed.

Oh, hm.  I thought that in the thread leading up to this email,
the original reporter said that in a kernel with CONFIG_USER_NS=n,
an unprivileged user could setns(fd) to an fd sent by a privileged
process, whereas the same situation with CONFIG_USER_NS=y was not
allowed.  I probably misunderstood.

-serge

Re: Requirements for CAP_SYS_ADMIN on setns() ?

[Eric W. Biederman]

"Serge E. Hallyn" <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org> writes:

> Quoting Eric W. Biederman (ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org):
>> Serge Hallyn <serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org> writes:
>> 
>> > Quoting Daniel P. Berrange (berrange-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org):
>> >> Is it not sufficient to rely on the permissions on the /proc/$PID/ns/XXX
>> >> file to control access to a namespace, and thus allow setns() without
>> >> a CAP_SYS_ADMIN check ?

The permissions on /proc/$PID/ns/XXX are sufficient to control access
but they are not ok to allow use.

>> >> ie setns() is basically useless unless you
>> >> already have sufficient privileges to get a file descriptor for the
>> >> namespace, so why does setns need an additional privilege check beyond
>> >> that done at time of open() on the proc file.

To be very clear.

setns requires CAP_SYS_ADMIN because changing the namespaces for your
children can result in tricking a suid root application and thus lead
to privilege escalation.

If you run setns inside a user namespace that you control the privilege
escalation is not possible and so setns is allowed.

Eric

Re: Requirements for CAP_SYS_ADMIN on setns() ?

[Daniel P. Berrange]

On Thu, Jun 06, 2013 at 11:15:11AM -0700, Eric W. Biederman wrote:
> "Serge E. Hallyn" <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org> writes:
> 
> > Quoting Eric W. Biederman (ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org):
> >> Serge Hallyn <serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org> writes:
> >> 
> >> > Quoting Daniel P. Berrange (berrange-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org):
> >> >> Is it not sufficient to rely on the permissions on the /proc/$PID/ns/XXX
> >> >> file to control access to a namespace, and thus allow setns() without
> >> >> a CAP_SYS_ADMIN check ?
> 
> The permissions on /proc/$PID/ns/XXX are sufficient to control access
> but they are not ok to allow use.
> 
> >> >> ie setns() is basically useless unless you
> >> >> already have sufficient privileges to get a file descriptor for the
> >> >> namespace, so why does setns need an additional privilege check beyond
> >> >> that done at time of open() on the proc file.
> 
> To be very clear.
> 
> setns requires CAP_SYS_ADMIN because changing the namespaces for your
> children can result in tricking a suid root application and thus lead
> to privilege escalation.

Yep, ok I see that from the example shown earlier in the thread.

> If you run setns inside a user namespace that you control the privilege
> escalation is not possible and so setns is allowed.

What are the privilege requirements for being able to call setns() on
a user namespace FD ?


Thinking some more, if there was a setpidns(pid_t containerpid) syscall
which unconditionally joined the caller to all namespaces associated with
the target pid, then you'd not have the security risk described, right ?

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Re: Requirements for CAP_SYS_ADMIN on setns() ?

[Eric W. Biederman]

"Daniel P. Berrange" <berrange-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> writes:

> On Thu, Jun 06, 2013 at 11:15:11AM -0700, Eric W. Biederman wrote:
>> "Serge E. Hallyn" <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org> writes:
>> 
>> > Quoting Eric W. Biederman (ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org):
>> >> Serge Hallyn <serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org> writes:
>> >> 
>> >> > Quoting Daniel P. Berrange (berrange-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org):
>> >> >> Is it not sufficient to rely on the permissions on the /proc/$PID/ns/XXX
>> >> >> file to control access to a namespace, and thus allow setns() without
>> >> >> a CAP_SYS_ADMIN check ?
>> 
>> The permissions on /proc/$PID/ns/XXX are sufficient to control access
>> but they are not ok to allow use.
>> 
>> >> >> ie setns() is basically useless unless you
>> >> >> already have sufficient privileges to get a file descriptor for the
>> >> >> namespace, so why does setns need an additional privilege check beyond
>> >> >> that done at time of open() on the proc file.
>> 
>> To be very clear.
>> 
>> setns requires CAP_SYS_ADMIN because changing the namespaces for your
>> children can result in tricking a suid root application and thus lead
>> to privilege escalation.
>
> Yep, ok I see that from the example shown earlier in the thread.
>
>> If you run setns inside a user namespace that you control the privilege
>> escalation is not possible and so setns is allowed.
>
> What are the privilege requirements for being able to call setns() on
> a user namespace FD ?

That you are not threaded and the user namespace is a child of the
current user namespace that you have CAP_SYS_ADMIN rights over.

Essentially the requirement is that it is a user namespace that your uid
created.

> Thinking some more, if there was a setpidns(pid_t containerpid) syscall
> which unconditionally joined the caller to all namespaces associated with
> the target pid, then you'd not have the security risk described, right ?

The security risk is present unless you join the user namespace, as
namespaces can be a bit leaky (fd passing etc).  At the same time the
user namespace is sufficient to remove the security risk, as privilege
escalation is not possible in the user namespace so even if you fool a
suid application it does not matter.

Eric

Re: Requirements for CAP_SYS_ADMIN on setns() ?

[Rob Landley]

Waaaay behind on my email...

On 06/07/2013 04:34:59 AM, Daniel P. Berrange wrote:
> On Thu, Jun 06, 2013 at 11:15:11AM -0700, Eric W. Biederman wrote:
> > "Serge E. Hallyn" <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org> writes:
> > setns requires CAP_SYS_ADMIN because changing the namespaces for  
> your
> > children can result in tricking a suid root application and thus  
> lead
> > to privilege escalation.
> 
> Yep, ok I see that from the example shown earlier in the thread.
> 
> > If you run setns inside a user namespace that you control the  
> privilege
> > escalation is not possible and so setns is allowed.
> 
> What are the privilege requirements for being able to call setns() on
> a user namespace FD ?
> 
> Thinking some more, if there was a setpidns(pid_t containerpid)  
> syscall
> which unconditionally joined the caller to all namespaces associated  
> with
> the target pid, then you'd not have the security risk described,  
> right ?

Sounds like you want a reparent_to_init() that works for a container's  
init.

Rob

Re: Requirements for CAP_SYS_ADMIN on setns() ?

[Eric W. Biederman]

Rob Landley <rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org> writes:

> Waaaay behind on my email...
>
> On 06/07/2013 04:34:59 AM, Daniel P. Berrange wrote:
>> On Thu, Jun 06, 2013 at 11:15:11AM -0700, Eric W. Biederman wrote:
>> > "Serge E. Hallyn" <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org> writes:
>> > setns requires CAP_SYS_ADMIN because changing the namespaces for  
>> your
>> > children can result in tricking a suid root application and thus  
>> lead
>> > to privilege escalation.
>> 
>> Yep, ok I see that from the example shown earlier in the thread.
>> 
>> > If you run setns inside a user namespace that you control the  
>> privilege
>> > escalation is not possible and so setns is allowed.
>> 
>> What are the privilege requirements for being able to call setns() on
>> a user namespace FD ?
>> 
>> Thinking some more, if there was a setpidns(pid_t containerpid)  
>> syscall
>> which unconditionally joined the caller to all namespaces associated  
>> with
>> the target pid, then you'd not have the security risk described,  
>> right ?
>
> Sounds like you want a reparent_to_init() that works for a container's  
> init.

setns on all of the namespaces effectively gives you that ability.  You
probably want to play with cgroups and a few other similar things.  And
there is a utility in util-linux that automates at least the namespace
portion of this called nsenter.

Eric