Re: [RFC] Implement ambient capability set.

[Andy Lutomirski]

On Wed, Feb 4, 2015 at 1:27 PM, Serge E. Hallyn <serge@xxxxxxxxxx> wrote:
> Quoting Andy Lutomirski (luto@xxxxxxxxxxxxxx):
>> On Wed, Feb 4, 2015 at 1:16 PM, Serge E. Hallyn <serge@xxxxxxxxxx> wrote:
>> > Quoting Andy Lutomirski (luto@xxxxxxxxxxxxxx):
>> >> On Wed, Feb 4, 2015 at 10:49 AM, Christoph Lameter <cl@xxxxxxxxx> wrote:
>> >> > +
>> >> > +               if (!cap_valid(arg2))
>> >> > +                       return -EINVAL;
>> >> > +
>> >> > +               new =prepare_creds();
>> >> > +               if (arg3 == 0)
>> >> > +                       cap_lower(new->cap_ambient, arg2);
>> >> > +               else
>> >> > +                       cap_raise(new->cap_ambient, arg2);
>> >> > +               return commit_creds(new);
>> >> > +
>> >>
>> >> This let you add capabilities you don't even have to cap_ambient.  I'm
>> >> fine with that as long as the cap evolution rule changes, as above.
>> >
>> > How about if instead we do restrict it to what's in pP?  I don't
>> > want CAP_SETPCAP to become a cheap way to get all caps back.  With
>> > or without NNP.
>>
>> We'd also have to modify everything that can change pP to change pA as
>> well if we went this route.  I'd be okay with that, but it would make
>> the patch much larger, and I'm not entirely sure I see the benefit.
>> It would keep the number of possible states smaller, which could be
>> nice.
>
> Do you mean if we didn't require NNP?  I'm suggesting that even if
> we require NNP we should restrict any new bits added to pA to be
> in pP at the prctl call.  Then whether or not to drop them from
> pA when they are dropped from pP, I'm not yet certain.

I mean regardless of whether we require NNP.

I think that, unless we change the evolution rule, we would need to
drop from pA when bits are dropped from pP to preserve the idea that
dropping bits from pP drops them for good (as long as ruid != 0 or
some securebit is set).

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