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@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.targetJul 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 hardeningTo 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_SETUIDWithout 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=0750ExecStart=/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=yesCapabilityBoundingSet=~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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
