[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170706121755.nhem2vlrtsvzr22g@perpetual.pseudorandom.co.uk>
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
