Date: Thu, 6 Jul 2017 13:17:55 +0100 From: Simon McVittie <smcv@...ian.org> To: oss-security@...ts.openwall.com Subject: Re: systemd fails to parse user that should run service 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
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ