On 07/20/2015 02:34 PM, Reindl Harald wrote: > > > 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?
Exactly, it's the reason why I suspect something fishy is going on if people to harden services running UID=0 by taking away capabilities. > 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 Then you still have instant root through: drwx------. 2 root root 20 Feb 3 12:36 /var/spool/cron/ >> 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 And that's fine. But doing hardening for UID=0 services seems a very bad practice to me because it looks like someone is assuming that UID=0 without capabilities is just another “nobody” user. Which is not surprising, because capabilities are often advertised that way. -- Florian Weimer / Red Hat Product Security _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel