netdev - Re: [patch 1/1] connector/userns: replace netlink uses of cap

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]

Message-Id: <20120510.232156.402883000515302167.davem@davemloft.net>
Date:	Thu, 10 May 2012 23:21:56 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	akpm@...ux-foundation.org
Cc:	netdev@...r.kernel.org, ebiederm@...ssion.com, dhowells@...hat.com,
	james.l.morris@...cle.com, kaber@...sh.net, morgan@...nel.org,
	philipp.reisner@...bit.com, segoon@...nwall.com,
	serge.hallyn@...onical.com
Subject: Re: [patch 1/1] connector/userns: replace netlink uses of
 cap_raised() with capable()

From: akpm@...ux-foundation.org
Date: Fri, 04 May 2012 14:34:03 -0700

> In 2009 Philip Reiser notied that a few users of netlink connector
> interface needed a capability check and added the idiom
> cap_raised(nsp->eff_cap, CAP_SYS_ADMIN) to a few of them, on the premise
> that netlink was asynchronous.
> 
> In 2011 Patrick McHardy noticed we were being silly because netlink is
> synchronous and removed eff_cap from the netlink_skb_params and changed
> the idiom to cap_raised(current_cap(), CAP_SYS_ADMIN).
> 
> Looking at those spots with a fresh eye we should be calling
> capable(CAP_SYS_ADMIN).  The only reason I can see for not calling capable
> is that it once appeared we were not in the same task as the caller which
> would have made calling capable() impossible.
> 
> In the initial user_namespace the only difference between between
> cap_raised(current_cap(), CAP_SYS_ADMIN) and capable(CAP_SYS_ADMIN) are a
> few sanity checks and the fact that capable(CAP_SYS_ADMIN) sets
> PF_SUPERPRIV if we use the capability.
> 
> Since we are going to be using root privilege setting PF_SUPERPRIV seems
> the right thing to do.
> 
> The motivation for this that patch is that in a child user namespace
> cap_raised(current_cap(),...) tests your capabilities with respect to that
> child user namespace not capabilities in the initial user namespace and
> thus will allow processes that should be unprivielged to use the kernel
> services that are only protected with cap_raised(current_cap(),..).
> 
> To fix possible user_namespace issues and to just clean up the code
> replace cap_raised(current_cap(), CAP_SYS_ADMIN) with
> capable(CAP_SYS_ADMIN).
> 
> Signed-off-by: Eric W. Biederman <ebiederm@...ssion.com>
> Cc: Patrick McHardy <kaber@...sh.net>
> Cc: Philipp Reisner <philipp.reisner@...bit.com>
> Acked-by: Serge E. Hallyn <serge.hallyn@...onical.com>
> Acked-by: Andrew G. Morgan <morgan@...nel.org>
> Cc: Vasiliy Kulikov <segoon@...nwall.com>
> Cc: David Howells <dhowells@...hat.com>
> Reviewed-by: James Morris <james.l.morris@...cle.com>
> Cc: David Miller <davem@...emloft.net>
> Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>

Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html