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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 4 Feb 2015 08:34:31 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	"Andrew G. Morgan" <morgan@...nel.org>
Cc:	"Serge E. Hallyn" <serge@...lyn.com>,
	Christoph Lameter <cl@...ux.com>,
	Serge Hallyn <serge.hallyn@...ntu.com>,
	Serge Hallyn <serge.hallyn@...onical.com>,
	Jonathan Corbet <corbet@....net>,
	Aaron Jones <aaronmdjones@...il.com>,
	"Ted Ts'o" <tytso@....edu>,
	LSM List <linux-security-module@...r.kernel.org>,
	lkml <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...uxfoundation.org>
Subject: Re: [capabilities] Allow normal inheritance for a configurable set of capabilities

On Wed, Feb 4, 2015 at 8:12 AM, Andrew G. Morgan <morgan@...nel.org> wrote:
> I was thinking more like this:
>
>     int override = secure(SECURE_AMBIENT_PRIVS) &&
> cap_isclear(caps->inheritable.cap);
>
>     CAP_FOR_EACH_U32(i) {
>         __u32 permitted = caps->permitted.cap[i];
>         __u32 inheritable = override ? new->cap_bset.cap[i] :
> caps->inheritable.cap[i];
>     [...]

To elaborate on my objection:

For better or for worse, as a practical matter, if you drop a cap from
pP but keep it in pI, there's no way to get that cap back on the
average system to get that cap back using execve because nothing will
have that bit set in fI.  I am not at all confident that changing this
is safe at this point, since there's lots of legacy code out there.

So, how about:

__u32 inheritable = override ? (new->cap_bset.cap[i] & permitted) :
caps->inheritable.cap[i];

instead?

This still doesn't address the effective set adequately, I think.  I
suspect that we'll want to always start with pE' == pP' in the new
mode, or perhaps pE' = (pP' & pE).  This latter part is also a bit
dangerous and furthers my desire to restrict this to no_new_privs.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ