linux-kernel - Re: [capabilities] Allow normal inheritance for a configurable set of capabilities

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]

Message-ID: <CALQRfL5L9c=M-+XL5GVEWHEJ6MuL-Xfsz_Kf7qpJQ3di4NvfRg@mail.gmail.com>
Date:	Wed, 4 Feb 2015 08:54:37 -0800
From:	"Andrew G. Morgan" <morgan@...nel.org>
To:	Andy Lutomirski <luto@...capital.net>
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

If permitted is zero (ie., no file capabilities) then I don't think
this will yield any privilege for such an exec. Perhaps I missed
something prior to being included in the thread, but I was under the
impression that this was a case where it was intended that
capabilities would be inherited..?

If you force pE' too, then this looks more like a mini-root
inheritance which gets me closer to disliking this: you need to
consider that we dangerously close to returning to situations like the
one discussed here:
https://sites.google.com/site/fullycapable/Home/thesendmailcapabilitiesissue

Cheers

Andrew


On Wed, Feb 4, 2015 at 8:34 AM, Andy Lutomirski <luto@...capital.net> wrote:
> 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/