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:	Tue, 3 Feb 2015 15:17:44 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	Christoph Lameter <cl@...ux.com>
Cc:	Casey Schaufler <casey@...aufler-ca.com>,
	"Serge E. Hallyn" <serge@...lyn.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>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...uxfoundation.org>
Subject: Re: [capabilities] Allow normal inheritance for a configurable set of capabilities

On Tue, Feb 3, 2015 at 3:14 PM, Christoph Lameter <cl@...ux.com> wrote:
> On Tue, 3 Feb 2015, Andy Lutomirski wrote:
>
>> >                  */
>> >                 new->cap_permitted.cap[i] =
>> >                         (new->cap_bset.cap[i] & permitted) |
>> > -                       (new->cap_inheritable.cap[i] & inheritable);
>> > +                       (new->cap_inheritable.cap[i] & inheritable) |
>> > +                       (ambient & inheritable);
>>
>> Is there a clear reason why no non-permitted bits can be inheritable?
>> If not, then I think this should be (ambient & inheritable &
>> permitted).
>
> Inherited caps via ambient are always be permitted. Otherwise the pass
> through is not working.

Sure, but what about inheritable caps before exec?  Suppose I drop
some cap from the permitted set but leave it in the inheritable set.
I shouldn't get it back by calling execve.

>
>> Do we need to think about the effective mask here?  What happens when
>> we exec a setuid program or a program with a non-empty fP set?  I
>> think that, in these cases, we should strongly consider clearing the
>> ambient set.  For a different approach, see below.
>>
>> >
>> >                 if (permitted & ~new->cap_permitted.cap[i])
>> >                         /* insufficient to execute correctly */
>> >                         ret = -EPERM;
>> > +
>> > +               if (capable(CAP_AMBIENT_MASK))
>> > +                       new->cap_ambient.cap[i] = inheritable;
>> > +               else
>> > +                       new->cap_ambient.cap[i] = ambient;
>>
>> IMO this is really weird.  I don't think that the presence of an
>> effective cap should change the cap equations.  (Also, that should be
>> nsown_capable.)
>
> Well how would the ambient mask to be set? The other options are adding a
> new syscall and having to go through an interation of the capabilities
> tools and/or kernel syscall API changes.

prctl?

>
>> Can we please make this an explicit opt-in?  For example, allow a
>> process to set an ambient cap bit if that bit is both permitted and
>> inheritable.  I'd prefer having it be a single control, though -- just
>> prctl(PR_SET_ALWAYS_INHERIT_CAPS, 1, 0, 0, 0) would set a single bit
>> that would cause all inheritable bits to be treated as ambient.
>
> Opt-in does not work since the caps need to be passed
> through binaries that do not use the capabilities.
>
>> Here's a slight variant that might be more clearly safe: add an
>> inherited per-process bit that causes all files to act as though fI is
>> the full set.  Only allow setting that bit if no_new_privs is set.
>
> CAP_INHERIT_ALL ?
>

Sure.  Would this approach work for your use case?  It would work for
mine, and it avoids needing to think about how this new kind of
inheritance would interact with setuid, setgid, and file caps (i.e. it
wouldn't, because you have to turn on off to get the other).

Opt-in should work fine as long as the opt-in is inherited.

--Andy

-- 
Andy Lutomirski
AMA Capital Management, LLC
--
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/