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

[Reindl Harald]

Am 20.07.2015 um 13:58 schrieb 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.

why should it need CAP_DAC_OVERRIDE when it *owns* the files and has 
write permissions? chown the file to a different user and root no longer 
can write there

to protect /etc and /usr "ReadOnlyDirectories" is the way to go
ReadOnlyDirectories=/etc
ReadOnlyDirectories=/usr
____________________________________________

[root at srv-rhsoft:~]$ cat /etc/systemd/system/test3.service
[Unit]
Description=Test Unit

[Service]
Type=oneshot
ExecStart=/usr/bin/touch /etc/passwd
PrivateTmp=yes
PrivateDevices=yes
NoNewPrivileges=yes
CapabilityBoundingSet=CAP_NET_BIND_SERVICE

[Install]
WantedBy=multi-user.target

Jul 20 14:25:59 srv-rhsoft touch: /usr/bin/touch: „/etc/passwd“ kann 
nicht berührt werden: Keine Berechtigung
Jul 20 14:25:59 srv-rhsoft systemd: test3.service: main process exited, 
code=exited, status=1/FAILURE
Jul 20 14:25:59 srv-rhsoft systemd: Failed to start Test Unit.
____________________________________________

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

no, the reason starting Apache (as example) with CAP_DAC_OVERRIDE is 
that the master process needs it to read certificate files which are not 
readable by the user it uses after start

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

Apache does the switch away from UID=0

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

that's a different story and works for services wich don't need to read 
files only readable by root and not listening on privileged ports like 
mysqld and in that case even if there is a root exploit 
CapabilityBoundingSet would reduce the damage

[Service]
Type=simple
User=mysql
Group=mysql
RuntimeDirectory=mysqld
RuntimeDirectoryMode=0750
ExecStart=/usr/libexec/mysqld --defaults-file=/etc/my.cnf 
--pid-file=/run/mysqld/mysqld.pid
ExecStartPost=/usr/libexec/mysqld-wait-ready $MAINPID
Environment="LANG=en_GB.UTF-8"
Restart=always
RestartSec=1
TimeoutSec=300
LimitNOFILE=infinity
LimitMEMLOCK=infinity
OOMScoreAdjust=-1000

PrivateTmp=yes
PrivateDevices=yes
NoNewPrivileges=yes
CapabilityBoundingSet=~CAP_AUDIT_CONTROL CAP_AUDIT_WRITE 
CAP_DAC_OVERRIDE CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_SETGID 
CAP_SETUID CAP_SYS_ADMIN CAP_SYS_BOOT CAP_SYS_MODULE CAP_SYS_PTRACE
RestrictAddressFamilies=~AF_APPLETALK AF_ATMPVC AF_AX25 AF_IPX 
AF_NETLINK AF_PACKET AF_X25
SystemCallArchitectures=x86-64

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150720/43659e0b/attachment.sig>