[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1499269723.28229.2.camel@gmail.com>
Date: Wed, 05 Jul 2017 11:48:43 -0400
From: Daniel Micay <danielmicay@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: systemd fails to parse user that should run
service
On Wed, 2017-07-05 at 16:37 +0100, John Haxby wrote:
> On 05/07/17 16:06, Daniel Micay wrote:
> > On Wed, 2017-07-05 at 15:50 +0100, John Haxby wrote:
> > > On 05/07/17 14:53, Simon McVittie wrote:
> > > > On Wed, 05 Jul 2017 at 14:02:23 +0200, Casper.Dik@...cle.com
> > > > wrote:
> > > > > > 2) If user name specified in systemd unit file is
> > > > > > syntactically
> > > > > > correct
> > > > > > (according to systemd check) but user name does not exist
> > > > > > then
> > > > > > systemd
> > > > > > refuse to start that unit.
> > > > >
> > > > > Should systemd really valid usernames? I would think that you
> > > > > would
> > > > > either use getpwnam(username) and if that fails you may then
> > > > > parse
> > > > > it as a
> > > > > numeric value. If "0day" isn't a valid username according to
> > > > > getpwnam(),
> > > > > when converting it to a numeric uid should *also* fail because
> > > > > "0day"
> > > > > isn't a properly numeric value.
> > > >
> > > > It *does* fail. The problem is in the handling of that failure.
> > > > systemd
> > > > interprets that failure as "this line is nonsense, so behave as
> > > > though the
> > > > line didn't exist" rather than "this line can be positively
> > > > identified as
> > > > an attempt to name a nonexistent or unacceptable user, so fail
> > > > to
> > > > load
> > > > the unit". So User=7up does the same thing as User=0day - it
> > > > doesn't
> > > > run as uid 7, which is 'lp' on my Debian system.
> > >
> > >
> > > And therein lies the problem. "0day" and "7up" are valid user
> > > names
> > > according to Posix[1], they may or may not exist, but they are
> > > valid.
> > > You may think Posix is wrong to allow an initial digit, but that
> > > isn't
> > > the issue. The problem is that systemd treats an "invalid"
> > > username
> > > as
> > > either an integer or not specified and in either case this results
> > > in
> > > a
> > > program running as the wrong user, probably as root.
> > >
> > > Having systemd balk at what Posix considers to be a valid username
> > > is
> > > a
> > > bug that systemd is free to say "this is stupid, we're not
> > > allowing
> > > that". If, as appears to be the case, systemd says "that
> > > username is
> > > stupid, we're going to interpret it differently" then that's when
> > > we
> > > need a CVE because, to my mind on this hot and sunny say, that's
> > > systemd
> > > apparently doing something for security that it is not.
> > >
> > > jch
> > >
> > >
> > > [1]
> > > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03
> > > .htm
> > > l#tag_03_431
> >
> > https://github.com/shadow-maint/shadow/blob/master/libmisc/chkname.c
> > #L49
> >
> > POSIX also says "." is a portable character, which isn't allowed by
> > shadow either. What are distributions using to provide useradd if
> > not
> > shadow?
>
> Interesting. "useradd a.b" works on Fedora so I wonder what's
> different
> there?
It seems some distributions get useradd/userdel from somewhere else.
Maybe you have adduser from shadow? It'd be funny if they had different
rules enforced even for adduser vs. useradd...
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.
