lkml.org 
[lkml]   [2011]   [Nov]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 6/6] protect cap_netlink_recv from user namespaces
Quoting Eric W. Biederman (ebiederm@xmission.com):
> Eric Paris <eparis@redhat.com> writes:
>
> > On Tue, 2011-11-08 at 03:29 +0000, Serge E. Hallyn wrote:
> >> Quoting Eric Paris (eparis@redhat.com):
> >
> >> 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@redhat.com>
>
> Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
>
> 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


\
 
 \ /
  Last update: 2011-11-20 00:31    [W:0.054 / U:0.224 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site