Granting a capability to a service

[Lennart Poettering]

On Sat, 18.07.15 10:42, Florian Weimer (fweimer at redhat.com) wrote:

> Let's assume I want to start a service as an ordinary user, but allow to
> bind it to a privileged port.  The program implementing the service does
> not manipulate capabilities in any way.
> 
> I came up with with this system unit for testing purposes:
> 
> [Unit]
> Description=Test unit
> 
> [Service]
> Type=oneshot
> ExecStart=/usr/sbin/getpcaps self
> Capabilities=cap_net_bind_service+ep
> SecureBits=keep-caps
> User=fweimer
> StandardOutput=journal

Off-topic: This last line is implied, no need to specify.

> However, this does not work, the capability set remains empty.  Is there
> a way to achieve what I want?

No. Capabilities currently cannot be passed across exec() without fcaps...

> This design is really odd because setting file capabilities always
> increases the attack surface (even if it is just the inheritable bits),
> and the only alternative appears to modify the service so that it is
> capability-aware and switches away from UID 0, and grant sufficient
> capabilities so that it can do so.  At that point, you can just skip the
> configuration in the systemd service and do everything capablity-related
> within the program.

Yeah, Capabilities= is not particularly useful. CapabilityBoundingSet=
is much more useful, as that is not affected by fcaps. But then again,
it has quite a different effect...

What's worse is that in kernels before 2.6.24 passing caps across
exec() actually worked fine. Kernel broke API heavily in this regard
by introducing fcaps and altering the caps inheritance logic then. 

Lennart

-- 
Lennart Poettering, Red Hat