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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
