Our customers run a wide variety of systems so in order to support the poor ones who run Windows I do occasionally have to both provide a Windows build and perform QA.
And how often does CentOS/RHEL create conflicting libraries due to updates within the same major version? Have they even done it once? Sounds like they have from your post but I find that really strange since the big reason to have a stable release such as RHEL or any of the LTS systems from i.e Ubuntu is that they do not do changes like this.
This, a million times this! Consitency between how the code works on the servers and the dev machines is important to me and also it makes distribution far easier, you just have to scp over the binary.
Yeah right, the macOS GUI is so polished and nice that whenever I boot one up in Virtual Box I only ssh to it, at least Apple haven't managed to idiotize that yet.
Does not work if you want to provide proper QA to paying customers. Also one of our products puts data into MS SQL Server among other things and running that beast on Wine is no fun when you have some 200K updates per second.
Never ever, Ubuntu on the workstation and Windows 10 as a Virtual Box guest for the rare occasion where I have to make a Windows build (using GCC on MSYS2 since VS is cancer).
I prefer a proper workstation myself but all the other developers at work use laptops, I'm the outlier there. They claim it's so that they can take them home but at home I have another workstation with all the code on anyway so that one does not fully compute either.
Why am I not surprised that you can't imagine a reason to change a configurable option?
That is not what I wrote! If you change it then you have an equal responisibility as that of the maintainer, i.e you have to check that your change did what you expected it to do. Or are I'm to believe that you blindly make changes to systems without checking the result?
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."
Okey that one was stretching it a bit I admit but one such statement is far from "keep making". And there is a good reason why no sysv script changes the user but lets the daemon itself do it and that is due to the complexity needed to make su work here. 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.
None of this is of course impossible but AFAIK no one have yet bothered to do it this way leading us to a world where all sysv scripts execute as root and the responsibility to be able to drop privileges is left to the daemon itself, and have we checked the source of every such daemon to see if they exit if setuid() and/or getpwnam() fails?
So yes, the User= feature or systemd will lead to a more secure environment than what we had in the old sysv days not because it's impossible to do so under sysv but because it was too much trouble. And yes this bug in systemd puts some shame on this whole premise but I have a hard time seeing any one successfully exploiting this.
It's the exact opposite. Criticism, even mild criticism, even when the actual developers see it as a mistake is shouted down time after time by idiot fanboys blowing shit out of proportion. Are you going to act like one of those idiot fanboys or are you going to stop using lines like "systemd will eat your children and rape your pets" in response to a discussion about a real flaw that Lennert also sees as a real flaw?
So you can actually find a single post to this article that contains "mild criticism"?
It should be but it is not - that is the problem here. Someone else above provided a link to the bug report. Perhaps you should take a look at it and catch up on the subject being discussed instead of some sort of uninformed rant.
And from the actual bug report: "The 7oz test was perfect. Clearly the issue is not missing validation - in fact, the safe_atou function does exactly what it should..." and "The real bug is that invalid User= directives are skipped rather than rejecting the whole unit."
Perhaps you should examine why you experience so much corruption then. I've run journald for years now on lots of servers and have not to this day experienced a single corruption, and that is with servers that create GB:s of logs each day.
For your own systems yes, but we are talking about the UEFI Secure Boot which sends a single signed digest for the whole boot loader to UEFI. Of course you can create a shim in between which you boot into and which UEFI validates the digest for while your shim does this part-by-part validation of the kernel. So it should be possible to do.
Yes that is one of the major drawbacks of using a binary format for anything. There are upsides as well and speaking for myself since I have yet to encounter a corrupted logfile by either syslog or journald I find the upsides outweighing that downside.
I'm not defending him, I'm just not trying to play this whole "systemd will eat your children and rape your pets" scheme that the lot of you are playing at the moment. And this is hardly a newbie mistake, the input is checked and acted upon, it's not a mistake but a deliberate design. In your eyes that might make this worse but the thing is that there will not be a single system 0wned due to this. There will not be a single unit file from any distribution with a username that starts with a zero.
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.)
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?
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.
Sorry got confused, my bad. The new shell output the username of the new user which the whoami command also does which is why I was fooled (tested too quickly)
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.
Well I thought that no sysv script did that was afraid that if I claimed that this where the case then I would get 2 billion angry comments about that (I'm already getting tons of hate posts due to me not writing shit about systemd on this very article). 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.
Yes that LP closes bugs like this a bit too quick is a problem, I would however be concerned if he did so for something really serious and I have not seen him do that just yet so I'm not ready to throw him under the bus right now. Systemd is such a big improvement over sysv, upstart, smf, launchd and so on that he have done quite a lot of things right at least.
I never said that it wasn't a problem. But if you create your own unit files and never once looks at the logs or checks that it runs as the user you thought it should then this accidental typo could as easily be that you prefixed User= with #User= and thus turned it into a comment. Yes silly argument I know but so are your "LP must protect my from ever making a mistake".
You don't write init scripts and rpm/deb packages do you? Features like this, when we are talking about distro agnostic unit files, the rpm/deb/whatever creates a user with adduser in the postinst script with the same name that you then use in the User= stanza in the unit file. If this where for a sysv script you usually put the username in the daemon config instead (if the daemon supports changing user and/or group), which at the moment is also how 99% of the daemons on systemd distributions also handle this since the User= stanza have not been used yet.
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.
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.
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
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.
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.
But for this to work some one must have been also able to #1 put such an invalid username in the User= setting in this unit file and #2 the very some one must also have somehow convinced you that this particular unit runs under a different user account and #3 you never checked that it did.
#1 rules out any unit file supplied by a distribution so where did you get the unit file from. And if you never did #3 then that person could just as easily not have used the User= setting in the first place.
The end of it is that you simply cannot trust a random sysv script or systemd unit file regardless of if this bug is fixed or not. You must always check that it does what it claims it does. Do you now understand why I see this as a problem but not of a the sky is falling kind if problem?
Not if the kernel is signed and booted over secure boot, protecting against a possible exploited and hostile kernel is one of the things that secure boot was meant to stop.
Do I really have to tell you once again that systemd logs a warning when this happens?
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!"
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 just as you have to check all the unit files that claim to run under a different user and checking all the unit files is way easier "grep User=/lib/systemd/system/.*service" and see if any of them starts with a number. Far easier than to go over all the sysv scripts in order to find missing checks.
You claim that it's not a problem because you can't see a way to trivially exploit it. (You're wrong.)
So prove me wrong then. Please come up with a scenario where you can exploit this.
it's been closed with not-a-bug.
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.
Reading comprehension much? I did say that in his scenario the unit would not start. And btw good luck getting 0wned by a script kiddie due to this, if you are then you are the same with sysv since all sysv scripts runs as root.
Slashdot Mirror
Our customers run a wide variety of systems so in order to support the poor ones who run Windows I do occasionally have to both provide a Windows build and perform QA.
And how often does CentOS/RHEL create conflicting libraries due to updates within the same major version? Have they even done it once? Sounds like they have from your post but I find that really strange since the big reason to have a stable release such as RHEL or any of the LTS systems from i.e Ubuntu is that they do not do changes like this.
This, a million times this! Consitency between how the code works on the servers and the dev machines is important to me and also it makes distribution far easier, you just have to scp over the binary.
Yeah right, the macOS GUI is so polished and nice that whenever I boot one up in Virtual Box I only ssh to it, at least Apple haven't managed to idiotize that yet.
runit is not sysv though, it's compatible with sysv scripts but so are most other replacements including upstart and systemd of course.
So they ninja:d their way into your servers and put shitty drives in them or what?
Does not work if you want to provide proper QA to paying customers. Also one of our products puts data into MS SQL Server among other things and running that beast on Wine is no fun when you have some 200K updates per second.
Never ever, Ubuntu on the workstation and Windows 10 as a Virtual Box guest for the rare occasion where I have to make a Windows build (using GCC on MSYS2 since VS is cancer).
I prefer a proper workstation myself but all the other developers at work use laptops, I'm the outlier there. They claim it's so that they can take them home but at home I have another workstation with all the code on anyway so that one does not fully compute either.
Why am I not surprised that you can't imagine a reason to change a configurable option?
That is not what I wrote! If you change it then you have an equal responisibility as that of the maintainer, i.e you have to check that your change did what you expected it to do. Or are I'm to believe that you blindly make changes to systems without checking the result?
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."
Okey that one was stretching it a bit I admit but one such statement is far from "keep making". And there is a good reason why no sysv script changes the user but lets the daemon itself do it and that is due to the complexity needed to make su work here. 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.
None of this is of course impossible but AFAIK no one have yet bothered to do it this way leading us to a world where all sysv scripts execute as root and the responsibility to be able to drop privileges is left to the daemon itself, and have we checked the source of every such daemon to see if they exit if setuid() and/or getpwnam() fails?
So yes, the User= feature or systemd will lead to a more secure environment than what we had in the old sysv days not because it's impossible to do so under sysv but because it was too much trouble. And yes this bug in systemd puts some shame on this whole premise but I have a hard time seeing any one successfully exploiting this.
It's the exact opposite. Criticism, even mild criticism, even when the actual developers see it as a mistake is shouted down time after time by idiot fanboys blowing shit out of proportion. Are you going to act like one of those idiot fanboys or are you going to stop using lines like "systemd will eat your children and rape your pets" in response to a discussion about a real flaw that Lennert also sees as a real flaw?
So you can actually find a single post to this article that contains "mild criticism"?
It should be but it is not - that is the problem here. Someone else above provided a link to the bug report. Perhaps you should take a look at it and catch up on the subject being discussed instead of some sort of uninformed rant.
And from the actual bug report: "The 7oz test was perfect. Clearly the issue is not missing validation - in fact, the safe_atou function does exactly what it should..." and "The real bug is that invalid User= directives are skipped rather than rejecting the whole unit."
Perhaps you should examine why you experience so much corruption then. I've run journald for years now on lots of servers and have not to this day experienced a single corruption, and that is with servers that create GB:s of logs each day.
For your own systems yes, but we are talking about the UEFI Secure Boot which sends a single signed digest for the whole boot loader to UEFI. Of course you can create a shim in between which you boot into and which UEFI validates the digest for while your shim does this part-by-part validation of the kernel. So it should be possible to do.
Yes that is one of the major drawbacks of using a binary format for anything. There are upsides as well and speaking for myself since I have yet to encounter a corrupted logfile by either syslog or journald I find the upsides outweighing that downside.
I'm not defending him, I'm just not trying to play this whole "systemd will eat your children and rape your pets" scheme that the lot of you are playing at the moment. And this is hardly a newbie mistake, the input is checked and acted upon, it's not a mistake but a deliberate design. In your eyes that might make this worse but the thing is that there will not be a single system 0wned due to this. There will not be a single unit file from any distribution with a username that starts with a zero.
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.)
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?
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.
Sorry got confused, my bad. The new shell output the username of the new user which the whoami command also does which is why I was fooled (tested too quickly)
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.
Well I thought that no sysv script did that was afraid that if I claimed that this where the case then I would get 2 billion angry comments about that (I'm already getting tons of hate posts due to me not writing shit about systemd on this very article). 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.
Yes that LP closes bugs like this a bit too quick is a problem, I would however be concerned if he did so for something really serious and I have not seen him do that just yet so I'm not ready to throw him under the bus right now. Systemd is such a big improvement over sysv, upstart, smf, launchd and so on that he have done quite a lot of things right at least.
And you can create a program that reads and opens a corrupted journal file as well since the format is open.
I never said that it wasn't a problem. But if you create your own unit files and never once looks at the logs or checks that it runs as the user you thought it should then this accidental typo could as easily be that you prefixed User= with #User= and thus turned it into a comment. Yes silly argument I know but so are your "LP must protect my from ever making a mistake".
You don't write init scripts and rpm/deb packages do you? Features like this, when we are talking about distro agnostic unit files, the rpm/deb/whatever creates a user with adduser in the postinst script with the same name that you then use in the User= stanza in the unit file. If this where for a sysv script you usually put the username in the daemon config instead (if the daemon supports changing user and/or group), which at the moment is also how 99% of the daemons on systemd distributions also handle this since the User= stanza have not been used yet.
No, if the bug requires a specific linking order then this kind of bug will appear much less frequent.
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.
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.
You are speaking from ignorance. You can't actually use 'su' the way you're suggesting. This doesn't work:
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.
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.
But for this to work some one must have been also able to #1 put such an invalid username in the User= setting in this unit file and #2 the very some one must also have somehow convinced you that this particular unit runs under a different user account and #3 you never checked that it did.
#1 rules out any unit file supplied by a distribution so where did you get the unit file from. And if you never did #3 then that person could just as easily not have used the User= setting in the first place.
The end of it is that you simply cannot trust a random sysv script or systemd unit file regardless of if this bug is fixed or not. You must always check that it does what it claims it does. Do you now understand why I see this as a problem but not of a the sky is falling kind if problem?
Not if the kernel is signed and booted over secure boot, protecting against a possible exploited and hostile kernel is one of the things that secure boot was meant to stop.
But with a random kernel that "some day" can be a very long wait.
without any notification to the user.
Do I really have to tell you once again that systemd logs a warning when this happens?
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!"
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 just as you have to check all the unit files that claim to run under a different user and checking all the unit files is way easier "grep User= /lib/systemd/system/.*service" and see if any of them starts with a number. Far easier than to go over all the sysv scripts in order to find missing checks.
You claim that it's not a problem because you can't see a way to trivially exploit it. (You're wrong.)
So prove me wrong then. Please come up with a scenario where you can exploit this.
it's been closed with not-a-bug.
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.
Reading comprehension much? I did say that in his scenario the unit would not start. And btw good luck getting 0wned by a script kiddie due to this, if you are then you are the same with sysv since all sysv scripts runs as root.