Discussion:
Is there a reason to run systemd Units with root access?
Add Reply
Mariusz Wojcik
2017-07-04 20:33:54 UTC
Reply
Permalink
Raw Message
Hi,

I’m just asking because of the latest “not-a-bug” [1]. As far as I know, there aren’t many services that need full root access (maybe for getting a low port number). Except for that I don’t see many use cases. Therefore, I think it would be useful to make the decision for root access more explicit, e.g. User=root is needed to start units as root. Also I don’t think it is a sane default is to start any unit as root when there is no valid User property. Even the security of systemd would benefit because it would save people from accidentally running services as root.

Regards,
Mariusz Wojcik

[1]: https://github.com/systemd/systemd/issues/6237
Michael Chapman
2017-07-06 10:22:52 UTC
Reply
Permalink
Raw Message
Post by Mariusz Wojcik
Hi,
I’m just asking because of the latest “not-a-bug” [1]. As far as I know,
there aren’t many services that need full root access (maybe for getting
a low port number). Except for that I don’t see many use cases.
Therefore, I think it would be useful to make the decision for root
access more explicit, e.g. User=root is needed to start units as root.
Also I don’t think it is a sane default is to start any unit as root
when there is no valid User property. Even the security of systemd would
benefit because it would save people from accidentally running services
as root.
Making User= mandatory would be a backwards-incompatible change, and break
a *lot* of existing units. People understand that omitting Unit= on a
system unit means the unit runs as root, just as omitting it on a user
unit means the unit runs as that user. Breaking units that work perfectly
well right now and do exactly what the admin wanted them to do really
isn't an option.
Simon McVittie
2017-07-06 10:31:32 UTC
Reply
Permalink
Raw Message
Post by Mariusz Wojcik
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
Reindl Harald
2017-07-06 10:51:06 UTC
Reply
Permalink
Raw Message
I’m just asking because of the latest “not-a-bug” [1]. As far as I know,
there aren’t many services that need full root access (maybe for getting
a low port number). Except for that I don’t see many use cases.
Therefore, I think it would be useful to make the decision for root
access more explicit, e.g. User=root is needed to start units as root.
Also I don’t think it is a sane default is to start any unit as
root when there is no valid User property. Even the security of
systemd would benefit because it would save people from accidentally
running services as root.
answer from a sysadmin:

how do you imagine that every systemd-unit out there shipped by whatever
distribution and much more critical every unit in /etc/systemd/system/
would get modified (for the second case i maintain alone some hundret
spread ver 30 or so machines)

"there aren't many services that need full root access" is simply not
true at all, you just don't know enough software which needs to read
certificate files which are only accessable as root (or at least should)
and then drop privileges just as one example
Lennart Poettering
2017-07-10 08:49:45 UTC
Reply
Permalink
Raw Message
Hi,
I’m just asking because of the latest “not-a-bug” [1]. As far as I
know, there aren’t many services that need full root access (maybe
for getting a low port number). Except for that I don’t see many use
cases. Therefore, I think it would be useful to make the decision
for root access more explicit, e.g. User=root is needed to start
units as root. Also I don’t think it is a sane default is to start
any unit as root when there is no valid User property. Even the
security of systemd would benefit because it would save people from
accidentally running services as root.
Well, UNIX system services traditionally expect to be invoked as "root",
and then drop privs on their own, if they are well written, and
systemd was created to run UNIX system services, hence the default.

But yeah I think today it would be better for services to just let
systemd drop privs for them wherever possible. But it's hard to get
that into people's heads, and it needs to be done on a per-service
basis, so that the right user is used, and the right execution
parameters (for example ambient caps) are passed otherwise.

Lennart
--
Lennart Poettering, Red Hat
Reindl Harald
2017-07-10 08:56:37 UTC
Reply
Permalink
Raw Message
Post by Lennart Poettering
Hi,
I’m just asking because of the latest “not-a-bug” [1]. As far as I
know, there aren’t many services that need full root access (maybe
for getting a low port number). Except for that I don’t see many use
cases. Therefore, I think it would be useful to make the decision
for root access more explicit, e.g. User=root is needed to start
units as root. Also I don’t think it is a sane default is to start
any unit as root when there is no valid User property. Even the
security of systemd would benefit because it would save people from
accidentally running services as root.
Well, UNIX system services traditionally expect to be invoked as "root",
and then drop privs on their own, if they are well written, and
systemd was created to run UNIX system services, hence the default.
But yeah I think today it would be better for services to just let
systemd drop privs for them wherever possible. But it's hard to get
that into people's heads, and it needs to be done on a per-service
basis, so that the right user is used, and the right execution
parameters (for example ambient caps) are passed otherwise.
it's not only about "get into people's heads"

it just don't make any sense for services like a webserver which needs
to read certificate private keys but the user after drop privileges
should not be able to read that files in case someone manages to execute
code (which is not that hard when scripting langauges with commands like
exec are part of the game)

the same when you read configurations containing sensible passwords, you
do that before drop privileges and yes read memory with random executed
coide is way harder than a file with a known path

Loading...