linux-kernel - Re: [PATCH 6/6] protect cap_netlink

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Sat, 19 Nov 2011 23:25:37 +0000
From:	"Serge E. Hallyn" <serge@...lyn.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Eric Paris <eparis@...hat.com>, richard@....at,
	containers@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org, oleg@...hat.com, dhowells@...hat.com,
	akpm@...ux-foundation.org
Subject: Re: [PATCH 6/6] protect cap_netlink_recv from user namespaces

Quoting Eric W. Biederman (ebiederm@...ssion.com):
> Eric Paris <eparis@...hat.com> writes:
> 
> > On Tue, 2011-11-08 at 03:29 +0000, Serge E. Hallyn wrote:
> >> Quoting Eric Paris (eparis@...hat.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@...hat.com>
> 
> Acked-by: "Eric W. Biederman" <ebiederm@...ssion.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/