Re: Requirements for CAP_SYS_ADMIN on setns() ?

[ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (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