[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170706211258.gkd5rhnsononht6f@perpetual.pseudorandom.co.uk>
Date: Thu, 6 Jul 2017 22:12:58 +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 Thu, 06 Jul 2017 at 13:27:53 -0600, Leonid Isaev wrote:
> On Thu, Jul 06, 2017 at 03:02:07PM +0100, Simon McVittie wrote:
> > > The problem is that my new and shiny
> > > script won't work as intended on old systemD versions which silently ignore
> > > User= directive.
> >
> > I am not aware of any such version existing. The 2010 commit
> > "first attempt at proper service/socket logic", which was 6 months before
> > the release of systemd version 1 and was the first commit to introduce
> > ExecStart, also introduced User.
>
> OK, but then there is no excuse to silently ignore any kind of error in
> User=. If systemd can not start unit as a specified user, it must fail it, just
> like ExecStart: if the command specified there is not found
I agree, and this was already done for usernames that were parsed as
syntactically valid (User=whatever on a system where there is no 'whatever'
user). The issue here was a combination of two things:
* Usernames that were considered to be syntactically invalid went
through the error-handling code path for unknown configuration items
(ignored on the assumption that they are some future extension point,
rather than causing failure). https://github.com/systemd/systemd/pull/6300
has now been proposed to change this, for User and a few other key
directives. This is basically Felipe's suggestion from the systemd-devel
thread.
* What can be in a valid username is Unix folklore rather than a standard
(POSIX defines a subset of usernames that are portable, but does not
forbid systems from additionally accepting non-portable usernames, and
in practice they do), and systemd's idea of what is a syntactically
valid username accepts considerably fewer usernames than common
useradd implementations (indeed it doesn't accept all POSIX portable
user names either).
User="syntax error!" or User=0day (which are treated as equivalently
invalid, and go through the same code paths) were never "silently
ignored": they were ignored rather noisily, with multiple log messages
every time the unit in question was started.
> I thought the current behavior of ignoring some syntax "mistakes" was put in
> place by design because units have to be backwards copatible with older systemd
> versions.
Yes, it is: if some future systemd version adds a new directive,
perhaps AnonymizeMachineID or StackSizeMax or something,
it is a deliberate design choice that current systemd versions will
log a warning and ignore it. This lets upstreams be more aggressive
about enabling new features (many of which are non-critical but
good-to-have security hardening for services), without necessarily
having to wait for the systemd version that introduced those features to
become available in the oldest, most stable or most "enterprise"
distribution that they target.
This is a trade-off, and both possibilities (reject unknown directives,
or warn and ignore) are plausible design choices: which one is better is
a matter of opinion. The systemd developers chose to treat the advantages
of the warn-and-ignore approach as larger than its disadvantages.
In general the same is true for the *values* of directives: systemd needs
to choose something to do about known directives with values that it
cannot understand, and in general they are ignored with a warning on
the assumption that the new value is something that might have been
understood by a newer version of systemd. That isn't appropriate for
all directives, hence <https://github.com/systemd/systemd/pull/6300>.
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.
