Granting a capability to a service

[Florian Weimer]

On 07/18/2015 03:53 PM, Andrew Lutomirski wrote:

> Nothing.  Inheritable capabilities are nearly useless.

Wow.

The program that sparked this thread is a Go program.  So basically, we
have these options if we do not want to run with full capabilities:

(a) Run with UID=0 with restricted capabilities, like many systemd
services already do.  Do not use fscaps (which are not needed because of
the UID=0 special case).  This is rather pointless because UID=0 does
not need capabilities to compromise the system.

(b) Make a copy of the file, put it in a directory which only the
service user can read (or ship it with 750 permissions and the service
group controlling it), and set fscaps.  The downside is the large binary
size (it has to be a copy, a link won't work).  And the service user
could still run the service with command line options that allow
privilege escalation.

(c) Make a copy as above, but in a directory only readable by root.  Add
fscaps and make the binary SUID/SGID to service user/group.  This
prevents privilege escalation by the service user (because it won't be
able to execve the SUID/SGID/fscaps binary, and ptrace of the privileged
process is blocked).  The service might end up running with unintended
supplementary groups, though.  And there is the copy overhead.

(d) Change the Go program to optionally drop capabilities and switch the
user.  Do not use fscaps, and keep running it as full root initially.
This is the cleanest approach and what other services use, but I don't
think Go currently supports switching credentials in all threads in the
process.

(e) Have a helper/wrapper which does (d) and invokes the Go program
after all the work which requires capabilities.  Downsides are that this
not very general and works only for very specific use cases.  It also
interferes with built-in restarts of the service daemon (the restart
would have to be performed by systemd).

Ignoring the file copy overhead, (c) looks most promising.  Thoughts?

-- 
Florian Weimer / Red Hat Product Security