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

[Andy Lutomirski]

On Tue, Feb 3, 2015 at 3:14 PM, Christoph Lameter <cl@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/