Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx): > Eric Paris <eparis@xxxxxxxxxx> writes: > > > On Tue, 2011-11-08 at 03:29 +0000, Serge E. Hallyn wrote: > >> Quoting Eric Paris (eparis@xxxxxxxxxx): > > > >> But, regardless, your point is valid in that I'm not tightening down as > >> much as I could. So how about I don't change the security_netlink_recv() > >> and callers yet, and instead I change cap_netlink_recv() to do: > >> > >> if (!IN_ROOT_USER_NS && !cap_raised(current_cap(), cap)) > > > > Actually better thought. Remove the LSM hook altogether and just use > > capable() in the callers. This hook, being used this way, was > > introduced in c7bdb545 back when we took the effective perms from the > > skb. We don't use the skb any more since netlink is synchronous. This > > is functionally equivalent except the capabilities code checks against > > the init_user_ns (something we want) and it will now set PF_PRIV (which > > also seems like a good thing) Something like: > > > > security: remove the security_netlink_recv hook as it is equivalent to capable() > > > > Once upon a time netlink was not sync and we had to get the effective > > capabilities from the skb that was being received. Today we instead get > > the capabilities from the current task. This has rendered the entire > > purpose of the hook moot as it is now functionally equivalent to the > > capable() call. > > > > Signed-off-by: Eric Paris <eparis@xxxxxxxxxx> > > Acked-by: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx> > > Darn. I missed this one went it went past the first time. Let's do > this. > > As Serge pointed out checking against the user namespace of the network > namespace happens to be safe because the subsystems that are brittle > really have problems don't support multiple network namespaces. > > Still I like the idea of erring on the conservative side here and > making everything safe. We can open relax the restrictions later > by using ns_capable. I want to get to a point where it is safe > for an unprivileged user to create their own user namespace, > and most of that is just getting the capable calls correct. > > Eric > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Ok. Oh! This was a part of my new 6-patch set I was going to send, but when you pursuaded me that some were not worth it if you're rethinking the nature of uids, I only sent patch 1. I did queue up the patch at http://kernel.ubuntu.com/git?p=serge/linux-2.6.git;a=commit;h=b97c54cb518160466095db8f8d2ecf5bd4f81ce2 and tested it a bit in ltp (with userns both on and off). Eric Paris, would you like to resend it separately (with Eric's and my ack's, as above and at http://lkml.org/lkml/2011/11/9/195), or would you like me to do so? thanks, -serge _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
