[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1b6f7cd9-2eb7-2c2d-e2e0-327cf3dd1e82@oracle.com>
Date: Wed, 5 Jul 2017 15:50:17 +0100
From: John Haxby <john.haxby@...cle.com>
To: oss-security@...ts.openwall.com
Subject: Re: systemd fails to parse user that should run
service
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.html#tag_03_431
>
> % cat /etc/systemd/system/demo.service
> [Unit]
> Description=Demonstration
>
> [Service]
> Type=oneshot
> ExecStart=/usr/bin/id
> User=7up
> % sudo systemctl daemon-reload
> % sudo systemctl start demo.service
> % sudo systemctl status demo.service
> ...
> Jul 05 14:47:11 host systemd[1]: /etc/systemd/system/demo.service:7:
> Invalid user/group name or numeric ID, ignoring: 7up
> Jul 05 14:47:11 host systemd[1]: Starting Demonstration...
> Jul 05 14:47:11 host id[27282]: uid=0(root) gid=0(root) groups=0(root)
> Jul 05 14:47:11 host systemd[1]: Started Demonstration.
> Jul 05 14:47:11 host systemd[1]: /etc/systemd/system/demo.service:7:
> Invalid user/group name or numeric ID, ignoring: 7up
> Jul 05 14:47:17 host systemd[1]: /etc/systemd/system/demo.service:7:
> Invalid user/group name or numeric ID, ignoring: 7up
> Jul 05 14:48:25 host systemd[1]: /etc/systemd/system/demo.service:7:
> Invalid user/group name or numeric ID, ignoring: 7up
>
> (The error message in the Journal is presumably repeated because systemd
> re-parses User when looking for ExecStartPre, ExecStart, ExecStop and
> ExecStopPost commands, even though in this case there is only ExecStart.)
>
> The default user to run system units, if no user is specified, is root,
> because for system services that's the right thing more often than not,
> analogous to how LSB init scripts always run as root and can drop
> privileges themselves if they want to.
>
> 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.
