Re: Requirements for CAP_SYS_ADMIN on setns() ?

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