* thegarbz and the rest of the systemd fan club start pretending that just because this one bug isn't serious, the rest of the problems with systemd and its developers aren't real.
But they're not legal, and should NOT resolve. My DNS servers do not have the ancient msdos compatibility turned on, and reject them as they should.
Although apparently the behavior that it has is to strip out the offending characters and then try to resolve the result, which doesn't make a whole lot of sense either.
From the bug, it looks like the problem is caused by linking with libidn2, and support for that was marked as "experimental" in systemd, so this really doesn't matter much. You shouldn't be enabling experimental features in software unless you're willing to deal with potential problems.
So they're at least no longer doing the "fallback to root" behavior. Although they still didn't fix the problem of systemd incorrectly deciding that certain usernames are invalid.
Forgot to respond to this part; hate to let this little bit of misinformation to stay uncommented on.
The permissions is that your "0day" user must have execute rights on/usr/bin/ which it does not need if you use User= in systemd.
First off, I have no idea what you think you'd be accomplishing by denying the user id that is supposed to be running the daemon search permission (execute permission on the directories) for the executable that it is supposed to be executing. That's what those permissions are for, after all -- to define which users are or are not permitted to perform certain operations. If you want a particular user to be able to access an executable in a particular directory, you grant that user permission to do so.
Secondly, since your claim that systemd doesn't require the the user to have search permission sounded fishy, I checked it out.
exec_spawn() (src/core/execute.c) calls fork() to create the child process, and then calls exec_child(). exec_childs call enforce_user(), which switches the UID by calling setresuid(). It then calls execve() to execute whatever it needs to run.
execve() will fail with EACCES if search permission is denied on any portion of the path prefix for the executable file. So systemd will have the exact same behavior with regard to permissions as su or any other similar tool. That shouldn't be a surprise, since this is essentially exactly the same process that su uses.
Your 0day user also needs to have a shell, somehting that the User= in systemd doesn't need.
We've already established that using 'su' is not a requirement. The only reason we're even talking specifically about 'su' is because you keep bringing it up.
I've mostly kept responding because I'm curious exactly how much deeper you're going to dig yourself in. So far, it seems like you haven't hit the limit.
Yes there are other tools that don't have that limitation and you could write your own tools. But that is besides the point because I'm not talking from the "I hack on my own system" point of view, I'm talking about creating init scripts meant for distribution and that will work on all systems. When you do that you can not hope that the end user have daemontools installed or some other tool that does this for you. This is where systemd (and upstart before it) helps because it offers all this functionality and more as a base.
Init scripts are typically maintained per-distribution, and so will rely on tools present in that distribution. The utility of being able to distribute a common file to start a service is a point worth considering, but it is completely irrelevant to your claims that nobody uses this function.
You need an expect script if you plan to use su in a init script so that you can supply the password to it, your "su 0day -c/usr/bin/daemon" would just hang the the entire boot sequence waiting for interactive input.
You're looking more and more like either a troll or an idiot. If you don't know how su works, how about you try it instead of spouting more incorrect information? I gave you a script earlier that runs 'whoami' as a different user. It's just two lines long. How hard is it to run it instead of looking like a moron when you make incorrect claims about it?
"su" does not require a password when run as root. This whole expect script requirement is a fiction that you've invented.
And even with something like daemontools (which I have used extensively back when I wrote sysv scripts for Gentoo)
...uh huh. right. If you used them "extensively" and wrote init scripts, I'm pretty sure you'd be a little better informed about how they work.
...the daemon runs as a different user but not the rest of the sysv script,...
Nobody has objected to the script running as root. We also don't object to systemd running as root. Is this the strawman you're attempting to attack?
So show me a single sysv script shipped with any distribution that uses SU in order to run a daemon as a different user, a single one.
Although I don't know any good way to search all released init scripts for a distribution, the script "/etc/init.d/speech-dispatcher" on my debian stretch system runs the/usr/bin/speech-dispatcher daemon as the user "speech-dispatcher". This is done using "start-stop-daemon --user", which is a Debian-provided tool to start daemons.
(I'm not sure why you would be insistent on using "su" to achieve this.)
And there is a good reason why no sysv script changes the user but lets the daemon itself do it...
Totally, utterly false. Switching users in an init script is something that a fair number of scripts do, as you'd know if you bothered to google it.
First you need to have a user with a password since su does not work with passwordless users, then you need to use an expect script in order to send this password with your non interactive script, then you have to either give this user a valid shell which breaks a few of the reasons we used this user to begin with so you then have to enter the command to run as the shell which means that the daemon have to be in a path where this user have the right to execute it and it must also have execute rights on the daemon.
You are still talking complete nonsense. Yes, using 'su' only works for users with a password. There are other tools that don't have that limitation, if that's what you need. For instance, look up "setuidgid" from daemontools, which is specifically designed to address running daemons as a different userid -- the use case that you are now claiming that nobody does!
I don't know what you're trying to talk about with your stuff about expect scripts. As I've already mentioned, a perfectly acceptable way to start a daemon as user 0day is:
su 0day -c/usr/bin/daemon
No expect script needed. And as for what you're trying to say about permissions... of course the user that you're running as has to have permission to run the daemon. That's the whole point! What, do you think that doesn't hold true with systemd's "User=" option?
None of this is of course impossible but AFAIK no one have yet bothered to do it this way...
Apparently, "as far as you know" isn't very far at all. You probably should stop talking about topics that you obviously know next to nothing about.
Because you are developing a new daemon and testing out your unit/service file/script. Why else would you play around with the User= setting?
Why am I not surprised that you can't imagine a reason to change a configurable option?
So yes systemd can (if you use a username that starts with a zero) run your daemon as root just like sysv does in 100% of the time and still people claim that this bug of systemd makes it less secure than old sysv (I'm not saying that you claim this) while the User= feature of systemd actually makes for a more secure environment than sysv could ever achieve.
You're still talking utter nonsense.
In a sysv init script, if you want to run your daemon as a particular user, you add a line like the following:
su 0day -c/usr/bin/daemon
It's simple and it works. If you do give it an invalid username, it will fail to start the daemon, as one would expect, instead of running the daemon with elevated privileges.
Perhaps the reason you're getting all this "hate" is because you keep making obviously false statements? In this case that "the User= feature of systemd actually makes for a more secure environment than sysv could ever achieve."
With systemd you don't have to hunt down logfiles, you either issue a "systemctl status servicename" which gives you the last few log rows from the service or you issue "journalctl -u servicename" to get the full log of the service you just started.
How do I know I'm supposed to do that? I gave systemd a clear, correct directive, and it started the service. Why am I double checking that it did what I told it to do? (Well, unless I happen to know that systemd is total crap and so needs constant monitoring.)
Problem with this is that you just guessed now and didn't test it because it does work, su changes to the new user and the rest of the script runs as that very user. Yes I did just test it on my machine and "whoami" gave the name of the other user I put after su.
As a matter of fact, I did. What is your/bin/sh, and what was the exact script you ran? I have one redhat (/bin/sh is bash) and one debian (/bin/sh is dash) system, and neither one exhibits the behavior that you describe. The script, as I posted, will invoke a new login shell as the user, and then after you exit that shell, will run the whoami command. Given that this should be the expected behavior with any shell and any version of su, I have a hard time believing what you're saying.
More to the point, I defy you to find any existing sysv init script that tries to use that idiom. It's not an issue, and the fact that you think it is tells me that you don't really know what you're talking about.
Do you now understand why I see this as a problem but not of a the sky is falling kind if problem?
I don't think that the fact that systemd had this particular bug is a huge deal. It's symptomatic of the lack of foresight that we see in systemd a lot -- in this case, not fully thinking through the implications of simply ignoring a parsing error in a unit file -- but if the bug had been reported, accepted, and fixed, most people wouldn't have cared.
The fact that LP and friends refuse to fix it is the big deal.
Do I really have to tell you once again that systemd logs a warning when this happens?
Unless you happen to be monitoring the specific logfile where that is logged, you will never know. I have no idea where the hell systemd would log such a thing. And why would I be looking for it? I made a completely reasonable setting in the unit file, and the associated program started. I would have no reason to dig through logfiles to make sure that systemd actually did what it was told to do.
Only if you specifically check the exit code of su in your script, so you must manually check all sysv scripts that claim to run under a different user....
You are speaking from ignorance. You can't actually use 'su' the way you're suggesting. This doesn't work:
#!/bin/sh su user whoami
Instead, you have to use something like the following:
#!/bin/sh su user -c "whoami"
That will print "user", as expected. And if you give it a bad username, then instead you'll get:
[root@oc0114316170 ~]# sh test.sh su: user user does not exist
Under no circumstances will this construct end up running the 'whoami' command as root.
So prove me wrong then. Please come up with a scenario where you can exploit this.
This is security 101, dude. Take a service with one of any number of potential security problems -- a buffer overflow, for instance. Normally it is run under a non-root user account, but because of the systemd bug it is run as root instead. Abracadabra, systemd has turned a limited exposure into a local root exploit.
And please don't turn around and claim that that doesn't count because it requires a problem in another piece of software. Secure engineering means that you design your software to limit exposure from other sources.
The bug reads: "This conversation has been locked and limited to collaborators.". Perhaps that is how all bugs that are closed looks like (I don't use github) but if not then too me this sounds exactly what I wrote earlier.
The state of the bug is shown near the top. LP closed the bug, saying it's not-a-bug, and then locked the discussion, because he can't stand to have people point out that he's full of crap.
The goal really is to be distribution agnostic, that is why the master list of unit files are managed in a central location from which the various distributions fetches the majority of their unit files (and contribute changes). Things like exec of course does exist but if you use a distro specific script there then your unit file will not be accepted upstream, but writing your own personal unit files are of course ok.
Fixing this problem doesn't stop systemd from being distribution agnostic in any way. If he wants a policy of "no usernames starting with numerals in standardized unit files", that's fine. But refusing to fix a systemd problem for a completely valid configuration just because of his tremendous ego? Not acceptable.
This is hardly a security hole. All sysv scripts have run as root for ages without people crying wolf...
These aren't equivalent. In this case, the user is telling systemd to run something as another user, and systemd is ignoring that directive, without any notification to the user. So you end up with something that is intended to run as another user with root permissions.
With sysv init, the scripts are intended to run as root. If you want to run something from a sysv init script as a different user, that's easy to do with various tools. And guess what -- if those tools can't run the command as the specified user, they don't run the command. That's how you handle this situation correctly in a secure way. You don't say, "screw it, if I don't like the username I'll just run it as root instead!"
...and for this to impact your security you have to first come up with a way where I can attack you with this bug with no other possibility for me to run things as root on your system first.
Typical systemd apologism. LP claims that it's not a problem because any tool that can create one of these userids is broken. (He's wrong.) You claim that it's not a problem because you can't see a way to trivially exploit it. (You're wrong.) In both cases, you dismiss any criticism of systemd because you don't understand the underlying issues. We've see this happen over and over.
In the real world, most security exploits need multiple steps to exploit. Running software with elevated permissions is a classic security vulnerability. This is the kind of bug that turns a small problem into a gaping security hole.
All that said, I believe that this behaviour is going to change, LP is not the sole dictator of systemd and note that the bug on GitHub was not closed but closed for public discussion so to me this looks like they discuss it internally.
I've been a Debian user for a really long time and have put up with systemd since it's easier than trying to avoid it. But this has pretty much convinced me that I need to switch. I can't afford to allow these jokers to compromise the security of my system.
Nope, red hat permits it as well. It appears that the misconception came from the default behavior of the useradd tool, but that is hardly the definitive source of what is and is not permissible.
If the goal was really for all unit files to be distribution agnostic, then you'd have to disallow things like "exec" which obviously can't be guaranteed to have identical behavior. Of course, that would be a ridiculous limitation. A much more sensible approach would be to publish guidelines for portable unit files, but not have systemd exhibit broken behavior if someone doesn't follow them exactly.
In any case, LP's refusal to make any change should be considered completely unacceptable. It would be one thing if systemd threw an error in this case; at least then the user knows that they'll have to work around this bug. But allowing a security hole to persist after it's been reported? That's almost malicious.
I've thought that this would be an improvement for a while, especially when flying economy on a long international flight. You ought to be able to get the same density of people lying down as sitting, and I might be able to sleep on a flight for once.
That is a very tortured definition of "portable" in this context. You're essentially saying that you want unit files to be "portable" in that they can be used unchanged on every system using systemd, but you are achieving that by making systemd itself non-portable to any system that doesn't enforce the particular peculiar user name restrictions that systemd expects. So far, nobody has come up with a single system that actually disallows usernames starting with a number.
It is usually recommended to only use usernames that begin with a lower case letter or an
underscore, followed by lower case letters, digits, underscores, or dashes. They can end
with a dollar sign. In regular expression terms: [a-z_][a-z0-9_-]*[$]?
Note the use of the word "recommended." Not "required", or "mandatory." You're misinterpreting a convention as an actual rule.
What happens when someone creates a user whose username is purely numeric and that number is different from the uid? What happens when a hacker creates a user with a username of "1" (eg. the uid of root)? Should systemd treat that as root (assuming "1" is a uid) or as the user with username "1" (uid is above 100)?
It would be sensible to disallow creation of all-numeric user names, because of the reasons you stated (far too likely that somebody is doing something nasty.) But disallowing them really doesn't fall under systemd's purview, since systemd is not the manager of the username database. And even if we decided that all-numeric usernames should be disallowed, systemd's totally braindead behavior of granting root access if you try to use one would still be wrong.
In today's environment, we can't afford security to be an afterthought, especially in an extremely pervasive and complex piece of software like systemd.
For example, recently it was found that some tools to add users allow the username to start with a number, which isn't allowed by the spec and can result in such a user (e.g. "0day") getting root access. Been there for a long, long time because apparently no-one does even basic tests on such critical bits of software to make sure it complies with he established rules.
This is gold. You're throwing an absolute hissy fit over people saying that systemd is responsible for the bug in question. Then you turn around and claim that the real fault is in long-established tools for not following your (imagined) rules, and exposing a serious security bug in your new systemd code.
What we really need is people dedicated to testing important OS code. It's a boring job that no-one wants, and anyone who takes it on will probably give up quickly as their bug reports are met with abuse and indifference.
.... I bet you don't even realize the irony of this coming from a systemd supporter.
The rules for Linux user names say they must not start with a digit,
Where are you finding this documented?
As you have been informed repeatedly in this thread, the Linux kernel doesn't even use the concept of user names (it works with IDs instead), so your statement can't possibly be true. Apparently one particular tool, adduser, by default, enforces some extra rules, but that doesn't mean that those rules are universal to all Linux systems.
Linus has a rule "don't break userspace." Poettering's rule is apparently "let's break userspace every chance we get for no damn reason at all."
It requires existing root access in order to create a new user. So if someone exploits it, you are already fucked.
Not really. A really obvious way to exploit this: say someone manages to compromise the repository of a project that has a decent chance of being run by a "0day" user (apparently fairly common in some circles.) They add some code that opens a backdoor if the tool is run as root. A user downloads this software, installs it as the "0day" user, and then installs a completely innocuous unit file to start the tool as that user. At this point, the user would expect that damage would be limited to the user he had created if there is malicious code in the tool, but because Poettering doesn't believe in fixing problems, instead he just gave root access to the malicious tool.
So specifically what part of his argument makes you think he doesn't understand this? Because he seems to have addressed your points directly and with reasonable, factually and logically correct arguments.
Well, let's look at his arguements: First, he said:
Yes, as you found out "0day" is not a valid username.
Which is really damn obviously false, because the relevant standards permit it and various Linux systems permit it. It's only "not valid" as defined by systemd. Then he says:
1. systemd is not the one coming up with the restrictions on user names, and while some distributions are less restrictive, many do enforce the same restrictions as we do. In order to make systemd unit files portable between systems we'll hence enforce something that resembles more the universally accepted set, rather than accept the most liberal set possible.
Making things "portable" by restricting the configurations that systemd will work with? On what planet does that make any sense at all? It's not like correctly handling user names that Poettering doesn't use is going to break things on his computer; he just doesn't want to make a simple change to fix something because of his ego.
2. User= in unit files is about system users, not regular users, and I am pretty sure we should enforce a stricter regime about system users than regular users.
Since systemd doesn't get to dictate valid usernames, this isn't a reasonable argument.
3. In systemd we generally follow the rule that when we encounter a unit setting that does not validate syntax-wise we'll log about it and ignore it, for compat reasons. We do the same for User= here as for all other options. Note that if you specify a valid user name but where the user doesn't exist, then we'll instead fail the service on start, because in that case there's not just something wrong with the syntax the service author used but actually something inconsistent on the system, and that should be considered fatal.
This just demonstrates a lax attitute towards security. If the unit file specifies a "User=" line, then they obviously want to set a particular user to run the service, and unexpectedly running it as root is a security hole. The fact that Poettering can't see that after 10 seconds of thinking about it tells me that I wouldn't want his code anywhere near my system.
Poettering's "logic" is pretty much that he doesn't want to adhere to standards just because he doesn't want to. He spouts some nonsense about making the unit files "portable," but that argument really doesn't make any sense in the context of this bug -- how on earth can you justify misinterpreting a username that is valid on some systems as being "portable"?
Slashdot Mirror
You missed a step.
* thegarbz and the rest of the systemd fan club start pretending that just because this one bug isn't serious, the rest of the problems with systemd and its developers aren't real.
I hear that Poettering has declared ssh a "broken concept", and so he's going to pull telnetd into systemd instead and permanently block port 22.
But they're not legal, and should NOT resolve. My DNS servers do not have the ancient msdos compatibility turned on, and reject them as they should.
Although apparently the behavior that it has is to strip out the offending characters and then try to resolve the result, which doesn't make a whole lot of sense either.
From the bug, it looks like the problem is caused by linking with libidn2, and support for that was marked as "experimental" in systemd, so this really doesn't matter much. You shouldn't be enabling experimental features in software unless you're willing to deal with potential problems.
I would tend to agree. If it's 30kW at full power, and assuming $0.10 per kWh, then it's at least $3.00.
You should probably check your assumptions there. Your numbers are only true if you have to run the laser at 30 kW for a whole hour.
It does look like the security problem was fixed:
https://github.com/systemd/systemd/pull/6300
So they're at least no longer doing the "fallback to root" behavior. Although they still didn't fix the problem of systemd incorrectly deciding that certain usernames are invalid.
Forgot to respond to this part; hate to let this little bit of misinformation to stay uncommented on.
The permissions is that your "0day" user must have execute rights on /usr/bin/ which it does not need if you use User= in systemd.
First off, I have no idea what you think you'd be accomplishing by denying the user id that is supposed to be running the daemon search permission (execute permission on the directories) for the executable that it is supposed to be executing. That's what those permissions are for, after all -- to define which users are or are not permitted to perform certain operations. If you want a particular user to be able to access an executable in a particular directory, you grant that user permission to do so.
Secondly, since your claim that systemd doesn't require the the user to have search permission sounded fishy, I checked it out.
exec_spawn() (src/core/execute.c) calls fork() to create the child process, and then calls exec_child(). exec_childs call enforce_user(), which switches the UID by calling setresuid(). It then calls execve() to execute whatever it needs to run.
execve() will fail with EACCES if search permission is denied on any portion of the path prefix for the executable file. So systemd will have the exact same behavior with regard to permissions as su or any other similar tool. That shouldn't be a surprise, since this is essentially exactly the same process that su uses.
Your 0day user also needs to have a shell, somehting that the User= in systemd doesn't need.
We've already established that using 'su' is not a requirement. The only reason we're even talking specifically about 'su' is because you keep bringing it up.
I've mostly kept responding because I'm curious exactly how much deeper you're going to dig yourself in. So far, it seems like you haven't hit the limit.
Yes there are other tools that don't have that limitation and you could write your own tools. But that is besides the point because I'm not talking from the "I hack on my own system" point of view, I'm talking about creating init scripts meant for distribution and that will work on all systems. When you do that you can not hope that the end user have daemontools installed or some other tool that does this for you. This is where systemd (and upstart before it) helps because it offers all this functionality and more as a base.
Init scripts are typically maintained per-distribution, and so will rely on tools present in that distribution. The utility of being able to distribute a common file to start a service is a point worth considering, but it is completely irrelevant to your claims that nobody uses this function.
You need an expect script if you plan to use su in a init script so that you can supply the password to it, your "su 0day -c /usr/bin/daemon" would just hang the the entire boot sequence waiting for interactive input.
You're looking more and more like either a troll or an idiot. If you don't know how su works, how about you try it instead of spouting more incorrect information? I gave you a script earlier that runs 'whoami' as a different user. It's just two lines long. How hard is it to run it instead of looking like a moron when you make incorrect claims about it?
"su" does not require a password when run as root. This whole expect script requirement is a fiction that you've invented.
And even with something like daemontools (which I have used extensively back when I wrote sysv scripts for Gentoo)
...uh huh. right. If you used them "extensively" and wrote init scripts, I'm pretty sure you'd be a little better informed about how they work.
...the daemon runs as a different user but not the rest of the sysv script,...
Nobody has objected to the script running as root. We also don't object to systemd running as root. Is this the strawman you're attempting to attack?
So show me a single sysv script shipped with any distribution that uses SU in order to run a daemon as a different user, a single one.
Although I don't know any good way to search all released init scripts for a distribution, the script "/etc/init.d/speech-dispatcher" on my debian stretch system runs the /usr/bin/speech-dispatcher daemon as the user "speech-dispatcher". This is done using "start-stop-daemon --user", which is a Debian-provided tool to start daemons.
(I'm not sure why you would be insistent on using "su" to achieve this.)
Maybe people tend to run benchmarks on their brand-new hardware, and not the hardware that they've been using for a while?
Just a thought.
And there is a good reason why no sysv script changes the user but lets the daemon itself do it...
Totally, utterly false. Switching users in an init script is something that a fair number of scripts do, as you'd know if you bothered to google it.
First you need to have a user with a password since su does not work with passwordless users, then you need to use an expect script in order to send this password with your non interactive script, then you have to either give this user a valid shell which breaks a few of the reasons we used this user to begin with so you then have to enter the command to run as the shell which means that the daemon have to be in a path where this user have the right to execute it and it must also have execute rights on the daemon.
You are still talking complete nonsense. Yes, using 'su' only works for users with a password. There are other tools that don't have that limitation, if that's what you need. For instance, look up "setuidgid" from daemontools, which is specifically designed to address running daemons as a different userid -- the use case that you are now claiming that nobody does!
I don't know what you're trying to talk about with your stuff about expect scripts. As I've already mentioned, a perfectly acceptable way to start a daemon as user 0day is:
No expect script needed. And as for what you're trying to say about permissions ... of course the user that you're running as has to have permission to run the daemon. That's the whole point! What, do you think that doesn't hold true with systemd's "User=" option?
None of this is of course impossible but AFAIK no one have yet bothered to do it this way...
Apparently, "as far as you know" isn't very far at all. You probably should stop talking about topics that you obviously know next to nothing about.
Because you are developing a new daemon and testing out your unit/service file/script. Why else would you play around with the User= setting?
Why am I not surprised that you can't imagine a reason to change a configurable option?
So yes systemd can (if you use a username that starts with a zero) run your daemon as root just like sysv does in 100% of the time and still people claim that this bug of systemd makes it less secure than old sysv (I'm not saying that you claim this) while the User= feature of systemd actually makes for a more secure environment than sysv could ever achieve.
You're still talking utter nonsense.
In a sysv init script, if you want to run your daemon as a particular user, you add a line like the following:
It's simple and it works. If you do give it an invalid username, it will fail to start the daemon, as one would expect, instead of running the daemon with elevated privileges.
Perhaps the reason you're getting all this "hate" is because you keep making obviously false statements? In this case that "the User= feature of systemd actually makes for a more secure environment than sysv could ever achieve."
With systemd you don't have to hunt down logfiles, you either issue a "systemctl status servicename" which gives you the last few log rows from the service or you issue "journalctl -u servicename" to get the full log of the service you just started.
How do I know I'm supposed to do that? I gave systemd a clear, correct directive, and it started the service. Why am I double checking that it did what I told it to do? (Well, unless I happen to know that systemd is total crap and so needs constant monitoring.)
Problem with this is that you just guessed now and didn't test it because it does work, su changes to the new user and the rest of the script runs as that very user. Yes I did just test it on my machine and "whoami" gave the name of the other user I put after su.
As a matter of fact, I did. What is your /bin/sh, and what was the exact script you ran? I have one redhat (/bin/sh is bash) and one debian (/bin/sh is dash) system, and neither one exhibits the behavior that you describe. The script, as I posted, will invoke a new login shell as the user, and then after you exit that shell, will run the whoami command. Given that this should be the expected behavior with any shell and any version of su, I have a hard time believing what you're saying.
More to the point, I defy you to find any existing sysv init script that tries to use that idiom. It's not an issue, and the fact that you think it is tells me that you don't really know what you're talking about.
Do you now understand why I see this as a problem but not of a the sky is falling kind if problem?
I don't think that the fact that systemd had this particular bug is a huge deal. It's symptomatic of the lack of foresight that we see in systemd a lot -- in this case, not fully thinking through the implications of simply ignoring a parsing error in a unit file -- but if the bug had been reported, accepted, and fixed, most people wouldn't have cared.
The fact that LP and friends refuse to fix it is the big deal.
Do I really have to tell you once again that systemd logs a warning when this happens?
Unless you happen to be monitoring the specific logfile where that is logged, you will never know. I have no idea where the hell systemd would log such a thing. And why would I be looking for it? I made a completely reasonable setting in the unit file, and the associated program started. I would have no reason to dig through logfiles to make sure that systemd actually did what it was told to do.
Only if you specifically check the exit code of su in your script, so you must manually check all sysv scripts that claim to run under a different user....
You are speaking from ignorance. You can't actually use 'su' the way you're suggesting. This doesn't work:
Instead, you have to use something like the following:
That will print "user", as expected. And if you give it a bad username, then instead you'll get:
Under no circumstances will this construct end up running the 'whoami' command as root.
So prove me wrong then. Please come up with a scenario where you can exploit this.
This is security 101, dude. Take a service with one of any number of potential security problems -- a buffer overflow, for instance. Normally it is run under a non-root user account, but because of the systemd bug it is run as root instead. Abracadabra, systemd has turned a limited exposure into a local root exploit.
And please don't turn around and claim that that doesn't count because it requires a problem in another piece of software. Secure engineering means that you design your software to limit exposure from other sources.
The bug reads: "This conversation has been locked and limited to collaborators.". Perhaps that is how all bugs that are closed looks like (I don't use github) but if not then too me this sounds exactly what I wrote earlier.
The state of the bug is shown near the top. LP closed the bug, saying it's not-a-bug, and then locked the discussion, because he can't stand to have people point out that he's full of crap.
The goal really is to be distribution agnostic, that is why the master list of unit files are managed in a central location from which the various distributions fetches the majority of their unit files (and contribute changes). Things like exec of course does exist but if you use a distro specific script there then your unit file will not be accepted upstream, but writing your own personal unit files are of course ok.
Fixing this problem doesn't stop systemd from being distribution agnostic in any way. If he wants a policy of "no usernames starting with numerals in standardized unit files", that's fine. But refusing to fix a systemd problem for a completely valid configuration just because of his tremendous ego? Not acceptable.
This is hardly a security hole. All sysv scripts have run as root for ages without people crying wolf...
These aren't equivalent. In this case, the user is telling systemd to run something as another user, and systemd is ignoring that directive, without any notification to the user. So you end up with something that is intended to run as another user with root permissions.
With sysv init, the scripts are intended to run as root. If you want to run something from a sysv init script as a different user, that's easy to do with various tools. And guess what -- if those tools can't run the command as the specified user, they don't run the command. That's how you handle this situation correctly in a secure way. You don't say, "screw it, if I don't like the username I'll just run it as root instead!"
...and for this to impact your security you have to first come up with a way where I can attack you with this bug with no other possibility for me to run things as root on your system first.
Typical systemd apologism. LP claims that it's not a problem because any tool that can create one of these userids is broken. (He's wrong.) You claim that it's not a problem because you can't see a way to trivially exploit it. (You're wrong.) In both cases, you dismiss any criticism of systemd because you don't understand the underlying issues. We've see this happen over and over.
In the real world, most security exploits need multiple steps to exploit. Running software with elevated permissions is a classic security vulnerability. This is the kind of bug that turns a small problem into a gaping security hole.
All that said, I believe that this behaviour is going to change, LP is not the sole dictator of systemd and note that the bug on GitHub was not closed but closed for public discussion so to me this looks like they discuss it internally.
According to https://github.com/systemd/systemd/issues/6237, it's been closed with not-a-bug. I hope it gets fixed someday, but I'm not holding my breath.
I've been a Debian user for a really long time and have put up with systemd since it's easier than trying to avoid it. But this has pretty much convinced me that I need to switch. I can't afford to allow these jokers to compromise the security of my system.
Nope, red hat permits it as well. It appears that the misconception came from the default behavior of the useradd tool, but that is hardly the definitive source of what is and is not permissible.
If the goal was really for all unit files to be distribution agnostic, then you'd have to disallow things like "exec" which obviously can't be guaranteed to have identical behavior. Of course, that would be a ridiculous limitation. A much more sensible approach would be to publish guidelines for portable unit files, but not have systemd exhibit broken behavior if someone doesn't follow them exactly.
In any case, LP's refusal to make any change should be considered completely unacceptable. It would be one thing if systemd threw an error in this case; at least then the user knows that they'll have to work around this bug. But allowing a security hole to persist after it's been reported? That's almost malicious.
I've thought that this would be an improvement for a while, especially when flying economy on a long international flight. You ought to be able to get the same density of people lying down as sitting, and I might be able to sleep on a flight for once.
That is a very tortured definition of "portable" in this context. You're essentially saying that you want unit files to be "portable" in that they can be used unchanged on every system using systemd, but you are achieving that by making systemd itself non-portable to any system that doesn't enforce the particular peculiar user name restrictions that systemd expects. So far, nobody has come up with a single system that actually disallows usernames starting with a number.
That page says:
It is usually recommended to only use usernames that begin with a lower case letter or an
underscore, followed by lower case letters, digits, underscores, or dashes. They can end
with a dollar sign. In regular expression terms: [a-z_][a-z0-9_-]*[$]?
Note the use of the word "recommended." Not "required", or "mandatory." You're misinterpreting a convention as an actual rule.
What happens when someone creates a user whose username is purely numeric and that number is different from the uid? What happens when a hacker creates a user with a username of "1" (eg. the uid of root)? Should systemd treat that as root (assuming "1" is a uid) or as the user with username "1" (uid is above 100)?
It would be sensible to disallow creation of all-numeric user names, because of the reasons you stated (far too likely that somebody is doing something nasty.) But disallowing them really doesn't fall under systemd's purview, since systemd is not the manager of the username database. And even if we decided that all-numeric usernames should be disallowed, systemd's totally braindead behavior of granting root access if you try to use one would still be wrong.
In today's environment, we can't afford security to be an afterthought, especially in an extremely pervasive and complex piece of software like systemd.
For example, recently it was found that some tools to add users allow the username to start with a number, which isn't allowed by the spec and can result in such a user (e.g. "0day") getting root access. Been there for a long, long time because apparently no-one does even basic tests on such critical bits of software to make sure it complies with he established rules.
This is gold. You're throwing an absolute hissy fit over people saying that systemd is responsible for the bug in question. Then you turn around and claim that the real fault is in long-established tools for not following your (imagined) rules, and exposing a serious security bug in your new systemd code.
What we really need is people dedicated to testing important OS code. It's a boring job that no-one wants, and anyone who takes it on will probably give up quickly as their bug reports are met with abuse and indifference.
.... I bet you don't even realize the irony of this coming from a systemd supporter.
we have to have a security outfit running as user "0day", a username that is illegal on Linux but apparently some buggy tools allow,
You're asserting this over and over again with no proof. Point us to the documentation that shows that such usernames are illegal.
The rules for Linux user names say they must not start with a digit,
Where are you finding this documented?
As you have been informed repeatedly in this thread, the Linux kernel doesn't even use the concept of user names (it works with IDs instead), so your statement can't possibly be true. Apparently one particular tool, adduser, by default, enforces some extra rules, but that doesn't mean that those rules are universal to all Linux systems.
Linus has a rule "don't break userspace." Poettering's rule is apparently "let's break userspace every chance we get for no damn reason at all."
It requires existing root access in order to create a new user. So if someone exploits it, you are already fucked.
Not really. A really obvious way to exploit this: say someone manages to compromise the repository of a project that has a decent chance of being run by a "0day" user (apparently fairly common in some circles.) They add some code that opens a backdoor if the tool is run as root. A user downloads this software, installs it as the "0day" user, and then installs a completely innocuous unit file to start the tool as that user. At this point, the user would expect that damage would be limited to the user he had created if there is malicious code in the tool, but because Poettering doesn't believe in fixing problems, instead he just gave root access to the malicious tool.
So specifically what part of his argument makes you think he doesn't understand this? Because he seems to have addressed your points directly and with reasonable, factually and logically correct arguments.
Well, let's look at his arguements:
First, he said:
Yes, as you found out "0day" is not a valid username.
Which is really damn obviously false, because the relevant standards permit it and various Linux systems permit it. It's only "not valid" as defined by systemd.
Then he says:
1. systemd is not the one coming up with the restrictions on user names, and while some distributions are less restrictive, many do enforce the same restrictions as we do. In order to make systemd unit files portable between systems we'll hence enforce something that resembles more the universally accepted set, rather than accept the most liberal set possible.
Making things "portable" by restricting the configurations that systemd will work with? On what planet does that make any sense at all? It's not like correctly handling user names that Poettering doesn't use is going to break things on his computer; he just doesn't want to make a simple change to fix something because of his ego.
2. User= in unit files is about system users, not regular users, and I am pretty sure we should enforce a stricter regime about system users than regular users.
Since systemd doesn't get to dictate valid usernames, this isn't a reasonable argument.
3. In systemd we generally follow the rule that when we encounter a unit setting that does not validate syntax-wise we'll log about it and ignore it, for compat reasons. We do the same for User= here as for all other options. Note that if you specify a valid user name but where the user doesn't exist, then we'll instead fail the service on start, because in that case there's not just something wrong with the syntax the service author used but actually something inconsistent on the system, and that should be considered fatal.
This just demonstrates a lax attitute towards security. If the unit file specifies a "User=" line, then they obviously want to set a particular user to run the service, and unexpectedly running it as root is a security hole. The fact that Poettering can't see that after 10 seconds of thinking about it tells me that I wouldn't want his code anywhere near my system.
Poettering's "logic" is pretty much that he doesn't want to adhere to standards just because he doesn't want to. He spouts some nonsense about making the unit files "portable," but that argument really doesn't make any sense in the context of this bug -- how on earth can you justify misinterpreting a username that is valid on some systems as being "portable"?