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] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 19 Nov 2011 01:10:29 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Eric Paris <eparis@...hat.com>
Cc:	"Serge E. Hallyn" <serge@...lyn.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

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
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/