[systemd-devel] Use of capabilities in default service files

[Florian Weimer]

On 07/20/2015 01:52 PM, Reindl Harald wrote:
> 
> 
> Am 20.07.2015 um 13:24 schrieb Florian Weimer:
>> CapabilityBoundingSet=CAP_IPC_OWNER CAP_SETUID CAP_SETGID CAP_SETPCAP
>> m4_ifdef(`HAVE_SMACK', CAP_MAC_ADMIN )
>> …
>> What's the intent of these settings?  Is it a form of hardening?  If
>> yes, it is rather ineffective because UID=0 does not need any
>> capabilities to completely compromise the system.
> 
> UID=0 *does* need capabilities,

drwxr-xr-x. 2 root root   37 Jun 13 10:09 /etc/cron.d
-rw-r--r--. 1 root root 3068 Jul 17 19:47 /etc/passwd

UID=0 without CAP_DAC_OVERRIDE (or any other capabilities) can write to
these locations and escalate fairly directly to full root.

> that's the whole purpose of
> CapabilityBoundingSet and so yes it is a form of hardening

To me, it looks someone misunderstood the interactions between UID=0 and
capabilities.

> our internal httpd package is using the following options and when you
> remove CAP_NET_BIND_SERVICE it could not bind to port 80,
> 
> PrivateTmp=yes
> PrivateDevices=yes
> NoNewPrivileges=yes
> CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE
> CAP_SETGID CAP_SETUID

Without code in the daemon to switch away from UID=0, this is not a very
strong restriction (but CAP_DAC_OVERRIDE is root-equivalent anyway, so
it probably does not matter).

I found the “CapabilityBoundingSet=” line (empty set) somewhat worrying,
it seems to me that this service should use a separate UID, not 0.

-- 
Florian Weimer / Red Hat Product Security