oss-sec mailing list archives
Re: systemd fails to parse user that should run service
From: Simon McVittie <smcv () debian org>
Date: Thu, 6 Jul 2017 13:17:55 +0100
On Wed, 05 Jul 2017 at 17:26:47 -0500, Patrick J. Volkerding wrote:
On 07/05/2017 04:14 PM, Robert Scheck wrote:+1 for both, the CVE and that this is a problem. The service should not be started with more (!) permissions simply if parsing username fails.One would think that without any User= line specified, defaulting to nobody:nogroup would be more sane than defaulting to root. Since the User= mechanism exists, if you want something to run as root, you should need to ask for it.
System services running as root are the common case: it's extremely common for a system service to either run as root all the time (e.g. BlueZ, ConnMan, NetworkManager), or start as root, do some privileged setup and drop privileges (e.g. dbus-daemon --system boosts its own file descriptor rlimit to mitigate denial of service attacks, before dropping privileges to a non-root user with no capabilities except possibly CAP_AUDIT_WRITE). systemd units are analogous to LSB init scripts, which all start as root, and drop privileges internally if they want to. Forcing User= to be explicitly given in every unit is certainly a design that the systemd developers could have chosen (dbus-daemon --system does make specifying a User compulsory in activatable system services' .service files, and will refuse to start the service without it). However, they didn't, and if they went back on that decision now, it would be a major compatibility break. You could call that a denial of service if you want to put it in more security-ish terms? :-) Technically, I think the default is "don't change uid" rather than "change to root", although the practical effect is the same for pid 1. systemd is also used as a per-user service manager, where User= would be inappropriate (and not work), and every service runs as the same uid as the `systemd --user` instance itself. Dropping privileges to nobody:nogroup is inappropriate, because services running as nobody are not protected from other services running as nobody. If a service does not need special privileges, then it should run as a system user that is only used by that service. S
Current thread:
- Re: systemd fails to parse user that should run service, (continued)
- Re: systemd fails to parse user that should run service Perry E. Metzger (Jul 05)
- Re: systemd fails to parse user that should run service Simon McVittie (Jul 05)
- Re: systemd fails to parse user that should run service Kristian Fiskerstrand (Jul 05)
- Re: systemd fails to parse user that should run service Jeremy Stanley (Jul 05)
- Re: systemd fails to parse user that should run service Kristian Fiskerstrand (Jul 05)
- Re: systemd fails to parse user that should run service Simon McVittie (Jul 05)
- Re: systemd fails to parse user that should run service Ben Tasker (Jul 06)
- Re: systemd fails to parse user that should run service Perry E. Metzger (Jul 05)
- Re: systemd fails to parse user that should run service Robert Scheck (Jul 05)
- Re: systemd fails to parse user that should run service Patrick J. Volkerding (Jul 06)
- Re: systemd fails to parse user that should run service Simon McVittie (Jul 06)
- Re: systemd fails to parse user that should run service Leonid Isaev (Jul 06)
- Re: systemd fails to parse user that should run service Simon McVittie (Jul 06)
- Re: systemd fails to parse user that should run service Leonid Isaev (Jul 06)
- Re: systemd fails to parse user that should run service Simon McVittie (Jul 06)
- Re: systemd fails to parse user that should run service Martin Steigerwald (Jul 06)
- Re: systemd fails to parse user that should run service Martin Steigerwald (Jul 06)