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]

Date:	Wed, 4 Feb 2015 18:34:47 +0100
From:	"Serge E. Hallyn" <serge@...lyn.com>
To:	"Andrew G. Morgan" <morgan@...nel.org>
Cc:	Andy Lutomirski <luto@...capital.net>,
	"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

Ok this is all sounding too magic for my tastes.  My original suggestion
was for an actual new capability set, pA, empty by default.  You can
add bits to it using prctl if ns_capable(CAP_SETPCAP) and all the new bits are
in your pE.  Once set, they stay until they are removed using prctl.  At
exec, pA' = pA, and fI |= pA (after reading fI from disk but before
calculating pI').

Quoting Andrew G. Morgan (morgan@...nel.org):
> 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/