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 at hallyn.com> writes:
> 
> > Quoting Eric W. Biederman (ebiederm at xmission.com):
> >> Serge Hallyn <serge.hallyn at ubuntu.com> writes:
> >> 
> >> > Quoting Daniel P. Berrange (berrange at redhat.com):
> >> >> 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 :|