Granting a capability to a service

[Steve Grubb]

On Monday, July 20, 2015 04:27:35 PM Florian Weimer wrote:
> >> The algorithm documented in capabilities(7) suggests that retaining
> >> effective capabilities across an execve system call absolutely requires
> >> file capabilities (the inheritable part).
> >
> > 
> >
> > No. You can start off as root, then change to your target uid retaining,
> > then open the socket. Just do it right away.
> 
> Sorry, but I don't see the contradiction.
> 
> As far as I can tell, you have to do all this before the execve
> (including the socket creation), or after the execve (and then execve
> with UID=0).  Without resorting to fscaps, it is not possible to set up
> the capabilities and user before the execve, and create the socket after
> it.  Without fscaps with a UID which is not 0, the capabilities are lost
> on execve.

Today, any application that wants to manipulate capabilities needs to be 
capability aware. You can use fs based capabilities, but it will be on even 
for children. This is because clearing the bounding set requires privs. Not to 
mention, attempting to clear the bounding set means the app is capabilities 
aware.


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

-Steve