[systemd-devel] Use of capabilities in default service files
Lennart Poettering
lennart at poettering.net
Wed Jul 22 12:39:53 PDT 2015
B1;4002;0cOn Mon, 20.07.15 13:58, Florian Weimer (fweimer at redhat.com) wrote:
> 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.
This could (and should) be combined with ProtectSystem=full to make
this effective.
Also, if the web server drops UID, then the bounding set has the
benefit that none but the specified caps can be reacquired via SUID
binaries or fcaps executables.
Again, caps do not exist in a vacuum. They are useful in conjunction
with other mechanisms, both within systemd, and in the daemons
themselves.
> > 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.
To me, it looks someone misunderstood that capabilities can be
combined with other mechanisms. ;-)
Lennart
--
Lennart Poettering, Red Hat
More information about the systemd-devel
mailing list