:: Re: [DNG] systemd allows elevated a…
Página Principal
Delete this message
Reply to this message
Autor: Adam Borowski
Data:  
Para: dng
Assunto: Re: [DNG] systemd allows elevated access from unit files?
On Tue, Jul 04, 2017 at 08:14:40PM +0900, Olaf Meeuwissen wrote:
> Evilham writes:
> > Hi there,
> >
> > Am 03/07/2017 um 16:08 schrieb dev:
> >>   "So, yeah, I don't think there's anything to fix in systemd here."
> >>    - Poettering

> >>
> >> Not sure what's more troubling here[1]; the lack of concern, the
> >> digression from POSIX, or the bug/backdoor itself. Maybe all three.
>
> Indeed and that's exactly why systemd shouldn't assume it's living in a
> Happy World of overly optimistic assumptions.
>
> > According to POSIX, a valid username may include: a-z, A-Z, 0-9, ., -, _
> > Where "-" cannot appear at the beginning. There is no further
> > restriction on the other chars.
> > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_435
>
> So if systemd were to adhere to POSIX (now I'm being overly optimistic,
> probably), systemd should check the user names in unit files for POSIX
> conformance and flatly refuse to do anything if they're not.


POSIX requires any system to accept _at_least_ this set of usernames.
You are free to accept anything else. UTF-8 letters come to mind.

[~]# useradd блядь
-- works ok.

[~]# adduser блядь
adduser: To avoid problems, the username should consist only of
letters, digits, underscores, periods, at signs and dashes, and not start with
a dash (as defined by IEEE Std 1003.1-2001). For compatibility with Samba
machine accounts $ is also supported at the end of the username

-- it adds @ anywhere and $ at the end.

> If systemd were to just take any user name, then it should *still* check
> that whatever user name it gets actuall corresponds to an existing user
> (and that that user is a system user to boot) before going ahead and
> doing anything.


Why would running services be restricted to system users only?

> Of course, all this checking negatively affect boot times so systemd
> simply assumes all's well ;-P


The fun thing is, sysvinit tends to win in boot times for quite a margin.

> > So, useradd works because it's lower level, adduser does not, because it
> > comes from shadow and they have more restrictions on what a valid name
> > is. IMHO that's a bug in shadow.
> > https://github.com/shadow-maint/shadow/blob/master/libmisc/chkname.c#L52
>
> On an even lower level, any text editor + shell combination will let you
> add accounts with whatever whacky user name you can think of. As far as
> /etc/passwd (and /etc/shadow) are concerned, the ':' is just about the
> only character you cannot use file format wise. Whether login (or your
> display manager) will let you login with that is another matter but for
> systemd unit files the capability to login is not required.


Well, and '\n'. But allowing '\n' in usernames would be about as bad an
idea as allowing them in file names. And no one would be insane enough to
do the latter, right? Right?

Another consideration is compatibility with AD+Samba. I'd find it
repugnant to let a Windows machine provide security, but it's a quite
widespread setup, which also allows usernames to start with a digit.

A more -- heck, most -- important concern is that my usual secondary
username is "1kb". Try to ban me and I'll bite. :þ

> > It is not possible, for example to execute: adduser name.lastname, which
> > is a valid POSIX username (but useradd name.lastname works fine).


Banning a naming scheme this widespread means someone needs to get his head
checked.


Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄⠀⠀⠀⠀ A master species delegates.