On 7/28/2015 8:06 AM, Serge E. Hallyn wrote: > On Tue, Jul 28, 2015 at 07:36:30AM -0700, Casey Schaufler wrote: >> On 7/26/2015 6:27 PM, Sungbae Yoo wrote: >>> So, Do you agree to allow the process to change its own labels? >> No. This requires CAP_MAC_ADMIN. Smack is mandatory access control. >> Being in a namespace (as they are implemented today) is not sufficient. > "requires CAP_MAC_ADMIN" should probably read "requires > CAP_MAC_ADMIN against initial user namespace." Any unprivileged > user can unshare a user_ns and get CAP_MAC_ADMIN.
As you say. Since the inode's xattrs are common you need privilege relative to the initial namespace. > > I'm terribly sorry I'm not yet caught up on the smack-lsm thread. > But intuitively I'd think that you'd want a way for smack policy > to say "this label is allowed to create a user-ns which will be > allowed to CAP_MAC_ADMIN", so then smack_capable() can use that > information to cleanly deny CAP_MAC_ADMIN in namespaces. > > -serge > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
