[systemd-devel] Is there a reason to run systemd Units with root access?
Simon McVittie
smcv at collabora.com
Thu Jul 6 10:31:32 UTC 2017
On Tue, 04 Jul 2017 at 20:33:54 +0000, Mariusz Wojcik wrote:
> As far as I know, there
> aren’t many services that need full root access (maybe for getting a low port
> number).
systemd system units are basically a replacement for LSB (or sysvinit
if you prefer) init scripts, which always run as full root, and can drop
privileges themselves if they want to.
Anything that runs with capabilities that trivially allow escalation to
full root (such as CAP_SYS_ADMIN, CAP_FSETID, CAP_SETUID, CAP_SYS_MODULE,
CAP_SYS_PTRACE) might as well be full root. Such processes are in the
trusted computing base (TCB): it would be within their technical ability
to break security policies.
Using an unscientific sample consisting of the 12 system services starting
with "a" or "b" on my Debian laptop:
* apt-cacher-ng has a non-trivial User (systemd starts it unprivileged)
* avahi-daemon starts as root to do some privileged setup, then drops
privileges itself (this is a common pattern, dbus-daemon does this too)
* alsa-{restore,state} don't necessarily need to be root, but do need
hardware access, are not persistent (they are "oneshot" services run
during boot and shutdown), and they are so simple that giving them
privilege separation seems like a poor use of anyone's time
* bluez runs as root but drops most capabilities
* the rest run as "full" root and are in the TCB, and seem like they
legitimately need it (for example atd and anacron have it as part of
their "API" that they can be used to run arbitrary tasks, including
being full root)
I personally think the syntactic/semantic validity distinction here
is not the least-astonishment behaviour, and my preferred resolution
for this issue would be for User=7up or User="this name is silly!" to
be exactly equivalent to specifying a User with a "normal" name that
happens to be missing from `getent passwd` (in other words, the unit
fails to start with exit status 217/USER). But you can tell I don't
think this is critically important by the fact that I haven't written
and proposed a patch with that behaviour. If this is more important to
you than it is to me, a reasonable next step would be to put together
that patch.
S
More information about the systemd-devel
mailing list