Granting a capability to a service

[Florian Weimer]

On 07/20/2015 05:59 PM, Steve Grubb wrote:

> Today, any application that wants to manipulate capabilities needs to be 
> capability aware.

The application does not want to manipulate capabilities.  I do not want
to run it as full root.  I don't want to add additional SUID/fscaps to
the file system.

It's somewhat silly to add a privilege escalation hatch to the file
system in order to run a daemon with *reduced* privileges.

>>>> The only way to bypass that
>>>> if you perform the execve call with UID 0 (i.e., the literal UID 0, not
>>>> a capability).
>>>
>>>
>>>
>>> Using libcap-ng, its 3 lines of code. Assuming the desired uid is 500:
>>>
>>>      capng_clear(CAPNG_SELECT_BOTH);
>>>      capng_update(CAPNG_ADD, CAPNG_EFFECTIVE|CAPNG_PERMITTED,
>>> CAP_NET_BIND_SERVICE); if (capng_change_id(500, 500, CAPNG_DROP_SUPP_GRP |
>>> CAPNG_CLEAR_BOUNDING)) error();
>>
>> But this requires changing the implementation of the service, right?
> 
> Yes. But doing this is so simple, that it shouldn't be a big deal. 3 lines of 
> code.

Ugh, not really.  Not if code creates threads before (the equivalent of)
the main() function is called.

glibc has code to deal with that (the setxid business).  It is rather
scary, but it does not cover capabilities (we could change that), and
does not help with binaries which do not link against glibc (which is
more difficult to change).

-- 
Florian Weimer / Red Hat Product Security