On Thu, Jun 06, 2013 at 11:15:11AM -0700, Eric W. Biederman wrote: > "Serge E. Hallyn" <serge@xxxxxxxxxx> writes: > > > Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx): > >> Serge Hallyn <serge.hallyn@xxxxxxxxxx> writes: > >> > >> > Quoting Daniel P. Berrange (berrange@xxxxxxxxxx): > >> >> 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 :| _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
