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 _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
