Quoting Paul Moore (paul@xxxxxxxxxxxxxx): > On Wednesday, January 15, 2014 06:25:05 PM Eric Paris wrote: Note first off that you'll rarely want to check for capabilities against yourself, because any unprivileged task can unshare a new user namespace with his own (host) uid mapped to root in the new namespace, and pass that test. However, checking for capabilities against an open file (meaning a inode_capable() check) makes sense. > > Just to blow everyone's minds: The first thought that came to me was > > that the only way to make this useful is to actually put a label on > > the user namespace. > > > > If I create a container, and then a container inside that container, > > I'd think selinux should be able to control the capabilities at the > > second level down. Dan's only asking about one level down... (Not sure whether you mean up or down? :) > Turtles all the way down. > > If we are going to do it for one level, we should do it for all levels. Speaking in non-selinux terms, it would make sense to simply ask whether task T1 has Capability C1 against object O1, where O1 is a task, a nic, a file, a mountpoint, etc. Referring to a specific user namespace by its own label would be awkward, I believe. I'm not sure how to put that in selinux terms, since labels will certainly cross namespaces. -serge _______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.