| View previous topic :: View next topic |
| Author |
Message |
Mr. T.
Guru
Joined: 26 Dec 2016
Posts: 477
|
 Posted: Sun Jul 02, 2017 8:21 pm Post subject: |
 |
|
| Hu wrote: | | Option (c) would be good because it would force the user to address the issue, either by renaming the account or by running the program as some other user. |
According to L. Poettering, the problem is related to compatibility. It is not a bug because it is an "expected" behavior so it would be more correct to say that this is a design problem. |
|
| Back to top |
|
 |
rob_dot_p
n00b
Joined: 28 Jan 2017
Posts: 30
|
| Posted: Sun Jul 02, 2017 8:43 pm Post subject: Re: https://github.com/systemd/systemd/issues/6237#issue-239 |
|
|
| helecho wrote: | It is not a bug. Indeed, the process of verifying the configuration is in line with their expectations:
- An invalid identifier is ignored;
- an invalid configuration will be rejected.
|
| Hu wrote: | | Option (b) would be nice, but not strictly required since that is not a well-formed username (according to man useradd. |
How does an upstream decision by shadow developers determine what's 'valid' though?
Are users on a Linux/Unix system, not added with a specific implementation of useradd, invalid? It doesn't violate POSIX.
The actual problem seems to be that systemd introduced an option which can take either a login name or a numeric UID as an argument:
| Quote: | User=, Group=
Set the UNIX user or group that the processes are executed as, respectively. Takes a single user or group name, or numeric ID as argument. |
https://www.freedesktop.org/software/systemd/man/systemd.exec.html#
They're making assumptions they shouldn't make and handle it badly if those assumptions aren't met. |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Sun Jul 02, 2017 8:44 pm Post subject: |
|
|
| Hu wrote: | For the benefit of people who do not follow the link provided by rob_dot_p (or if the thread is later edited, since Github permits that):
A user reported a bug where systemd was given a .service file that specified to run the process as the unprivileged user 0day. Contrary to user expectations, systemd ran the program as root. The systemd maintainer rejected the report as not-a-bug. In my opinion, systemd found the one unacceptable solution out of the possible ways to handle this:- Run the program with an account other than specified in the systemd service file
- Run the program as the specified user
- Refuse to run the program, citing an error in the configuration.
Option (a) is dangerous if the program is not meant to run with privilege and the user does not notice the problem. Option (b) would be nice, but not strictly required since that is not a well-formed username (according to man useradd). Option (c) would be good because it would force the user to address the issue, either by renaming the account or by running the program as some other user. |
Thing is having a username start with a number is valid. Coreutils provides means to deal with the associated ambiguity
https://www.gnu.org/software/coreutils/manual/coreutils.html#Disambiguating-names-and-IDs
Now having a string of number as a username is not the greatest for sure, but equally not sanitising your inputs is bad practice. https://xkcd.com/327/
the issue here isn't that such a username exists (it can), nor that it was created (some distro's help mitigate such ambiguity) BUT the fact that systemd barfed and executed the service as root ergo bug.
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54216
Location: 56N 3W
|
| Posted: Sun Jul 02, 2017 8:55 pm Post subject: |
|
|
Here comes useraddd and friends engulfed by systemd to fix a 'compatibility' problem.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Sun Jul 02, 2017 9:16 pm Post subject: |
|
|
| Naib wrote: | | the issue here isn't that such a username exists (it can), nor that it was created (some distro's help mitigate such ambiguity) BUT the fact that systemd barfed and executed the service as root ergo bug. |
I'm thinking that this can be an exploit. Use a username starting with a number and become root instead of getting an error message.
Last edited by Tony0945 on Sun Jul 02, 2017 9:21 pm; edited 1 time in total |
|
| Back to top |
|
|
proteusx
Guru
Joined: 21 Jan 2008
Posts: 338
|
| Posted: Sun Jul 02, 2017 9:21 pm Post subject: |
|
|
| Naib wrote: | | the issue here isn't that such a username exists (it can), nor that it was created (some distro's help mitigate such ambiguity) BUT the fact that systemd barfed and executed the service as root ergo bug. |
So if there exists an, according to systemd, "invalid" username then one can exploit it to execute 'rm -Rf /*' as root? |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Sun Jul 02, 2017 9:21 pm Post subject: |
|
|
| Tony0945 wrote: | | Naib wrote: | | the issue here isn't that such a username exists (it can), nor that it was created (some distro's help mitigate such ambiguity) BUT the fact that systemd barfed and executed the service as root ergo bug. |
I'm thinking that this can be an exploit. Use a username starting with a number and become root instead of getting an error message. |
An exploit that requires root to actually install a package that creates such a user & adds such a service file. but yes exploit. someone raised the concept of creating a CVE but well pottering and co have a habit of ignoring those OR silently fixing exploits that should be tracked ...
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21602
|
| Posted: Sun Jul 02, 2017 9:58 pm Post subject: |
|
|
| helecho wrote: | | According to L. Poettering, the problem is related to compatibility. It is not a bug because it is an "expected" behavior so it would be more correct to say that this is a design problem. |
Mr. Poettering always has an excuse. Ignoring unexpected directives is fine if ignoring them produces a reasonable result. Ignoring a User= directive is unlikely ever to produce a reasonable result. The problem is that the systemd parser conflated an unexpected directive with a directive it understands, but rejects because it dislikes the username. Ignoring unexpected hint directives is fine. Ignoring unexpected mandatory directives is wrong. Ignoring expected but ill-formed directives is wrong (taking, for the sake of generosity, systemd's definition of ill-formed, rather than the well-argued well-formedness definitions proposed in this thread). | rob_dot_p wrote: | | They're making assumptions they shouldn't make and handle it badly if those assumptions aren't met. |
| Naib wrote: | | the issue here isn't that such a username exists (it can), nor that it was created (some distro's help mitigate such ambiguity) BUT the fact that systemd barfed and executed the service as root ergo bug. |
I concur with both of you. I am willing to grant a bit of slack to developers who reject unusual valid inputs (believing them to be invalid inputs) if they reject them cleanly. This is not a clean rejection. It is a failure that ought to be fixed for the benefit of users who still use systemd. | Naib wrote: | | An exploit that requires root to actually install a package that creates such a user & adds such a service file. but yes exploit. someone raised the concept of creating a CVE but well pottering and co have a habit of ignoring those OR silently fixing exploits that should be tracked ... |
As someone suggested on the Github thread, administrators might install such a package on behalf of an unprivileged user if the administrator believes that the User= line does as it appears to do (rather than as it actually does). This is particularly bad since the administrator might check that the username exists, find that it does, and assume that the service will work as expected. Suppose someone requested and was granted an "ill-formed" username such as 7oz, used it for months, then asked for a systemd service to run as their user-id. The administrator reviews it, finds that the service has a proper User=, has an Exec= line that is reasonable for what the user is authorized to do, and installs it. The administrator is then shocked when systemd ignores the User= line because it considers the user's name to be ill-formed, so the service runs as root. |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Sun Jul 02, 2017 10:07 pm Post subject: |
|
|
exactly 
far too often I see people design stuff what what it should not NOT what it could do... its the typical bell curve test vectors. more and more I believe software and hardware should be subject to DO254,DO178,ARP4754 like processes ...
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Sun Jul 02, 2017 11:25 pm Post subject: |
|
|
| Naib wrote: | | far too often I see people design stuff what what it should not NOT what it could do... |
Sorry, Naib, I couldn't parse that sentence. As a favor, would you restate it, please? |
|
| Back to top |
|
|
Mr. T.
Guru
Joined: 26 Dec 2016
Posts: 477
|
| Posted: Mon Jul 03, 2017 5:30 am Post subject: |
|
|
In summary, many people do not understand why the service is run with the "root user" by systemd.
| Poettering wrote: | | 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. |
I interpret L. Poettering statements as follows: services are usually executed by specific users and these services are controlled by systemd; the root user is a particular system user.
If my interpretation is correct, the question that one might ask is how systemd controls services and why run the service with the root user and not with another system user?
N.B: I do not know systemd and I do not use it. |
|
| Back to top |
|
|
Mr. T.
Guru
Joined: 26 Dec 2016
Posts: 477
|
| Posted: Mon Jul 03, 2017 5:36 am Post subject: |
|
|
| Hu wrote: | | Ignoring unexpected mandatory directives is wrong. |
Is that the case?
| Hu wrote: | | Ignoring expected but ill-formed directives is wrong (taking, for the sake of generosity, systemd's definition of ill-formed, rather than the well-argued well-formedness definitions proposed in this thread). |
Maybe the systemd design allows it?
| Hu wrote: | | This is particularly bad since the administrator might check that the username exists, find that it does, and assume that the service will work as expected. |
| Poettering wrote: | | 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 my mind, the systemd developers should work (communicate) with other developers to solve this problem. |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Mon Jul 03, 2017 7:58 am Post subject: |
|
|
| rob_dot_p wrote: | NOT
A
BUG |
What's a bug is that systemd is written in unsafe C. They should port it to a bounds-checked language, I think PHP would be a good fit. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Mon Jul 03, 2017 9:50 am Post subject: |
|
|
| Hu wrote: | For the benefit of people who do not follow the link provided by rob_dot_p (or if the thread is later edited, since Github permits that):
A user reported a bug where systemd was given a .service file that specified to run the process as the unprivileged user 0day. Contrary to user expectations, systemd ran the program as root. The systemd maintainer rejected the report as not-a-bug. In my opinion, systemd found the one unacceptable solution out of the possible ways to handle this |
WTF?! All that turd-polishing about rejecting invalid configuration, and it does not even reject it. Words fail.
I concur; that has to be the most stupid way conceivable, to deal with it.
| Quote: | | Option (c)[refuse to run] would be good because it would force the user to address the issue, either by renaming the account or by running the program as some other user. |
Yes, that is the only way to deal with invalid configuration. Don't try to be smart, just bail out, and let the admin sort it out.
Whether you should reject a valid user account, ie one that is in the user db, is another matter. It's easiest just to look it up, and bail if it's not present; I cannot see the point in bothering to do more. We're not useradd, nor are we an administrator.
Ignoring your own validation, only allowing it to open a vector, is simply crap.
Just goes to show that Poeterring is still as full of bulshytt as ever.
He could have spent half the time he's spent on PR, on correcting the glaring problems, and pushing fixes, instead of fobbing everyone off with specious nonsense and labelling every hole NOT-A-BUG.
That he is pushing this notion of "does as intended" just brings to mind the old "it's not a bug, it's a feature" meme, and shows he simply has no clue about system design.
Any executive stupid enough to get caught up in the hype and allow this nub to be their backdoor system architect, deserves whatever they get. I suppose that's the silver-lining ;-) |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Mon Jul 03, 2017 9:52 am Post subject: |
|
|
| Ant P. wrote: | | What's a bug is that systemd is written in unsafe C. They should port it to a bounds-checked language, I think PHP would be a good fit. |
LOL.
I thought they were doing it in javascript.. using that mature, stable product v8. /sarcasm |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Mon Jul 03, 2017 11:04 am Post subject: |
|
|
| proteusx wrote: | | Naib wrote: | | the issue here isn't that such a username exists (it can), nor that it was created (some distro's help mitigate such ambiguity) BUT the fact that systemd barfed and executed the service as root ergo bug. |
So if there exists an, according to systemd, "invalid" username then one can exploit it to execute 'rm -Rf /*' as root? |
No. the simple existence of an "invalid" user isn't enough. A service file to be executed as said user is required.
If said service file then requested "rm -Rf /*" and this was installed then yes... but the question would have to be raised "why would an admin enable such a service" but that is the problem ... not all "exploits" are as clear as this
What if 7zip released some software that required a license manager. What if the license server had a buffer overflow bug. What if the admin installed the license manager & made a new user (best practice) to limit processes executed as root.
| Tony0945 wrote: | | Naib wrote: | | far too often I see people design stuff what what it should not NOT what it could do... |
Sorry, Naib, I couldn't parse that sentence. As a favor, would you restate it, please? |
Ahh sorry... that was very poorly written, even for me. " Far too often I see people design stuff for what it should do, NOT what it could do" Assuming a certain username grammar will always exists is poor.
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
Zucca
Moderator
Joined: 14 Jun 2007
Posts: 3339
Location: Rasi, Finland
|
| Posted: Mon Jul 03, 2017 11:22 am Post subject: |
|
|
| Hu wrote: | - Run the program with an account other than specified in the systemd service file
- Run the program as the specified user
- Refuse to run the program, citing an error in the configuration.
Option (a) is dangerous if the program is not meant to run with privilege and the user does not notice the problem. Option (b) would be nice, but not strictly required since that is not a well-formed username (according to man useradd). Option (c) would be good because it would force the user to address the issue, either by renaming the account or by running the program as some other user. |
I would expect c. Especially when it's about priviliges.
Ignoring setting(s) and running process without the invalid setting(s) just screams for privilige escalation. I'm not only talking about systemd. I think c choice should be common practice.
_________________
..: Zucca :..
Gentoo IRC channels reside on Libera.Chat.
--
| Quote: | | I am NaN! I am a man! |
|
|
| Back to top |
|
|
njharris
n00b
Joined: 17 Sep 2002
Posts: 13
|
| Posted: Mon Jul 03, 2017 12:10 pm Post subject: |
|
|
Aristotle (I believe) put it best, as modified by an Engineering Professor many years ago:
"Naively conceived and poorly executed, as if done by a college sophomore." |
|
| Back to top |
|
|
miket
Guru
Joined: 28 Apr 2007
Posts: 488
Location: Gainesville, FL, USA
|
| Posted: Mon Jul 03, 2017 3:53 pm Post subject: |
|
|
| Hu wrote: | | Suppose someone requested and was granted an "ill-formed" username such as 7oz, used it for months, then asked for a systemd service to run as their user-id. The administrator reviews it, finds that the service has a proper User=, has an Exec= line that is reasonable for what the user is authorized to do, and installs it. The administrator is then shocked when systemd ignores the User= line because it considers the user's name to be ill-formed, so the service runs as root. |
Actually, my guess is that systemd would try to run that service as lp (or whatever UID=7 is on that machine).
--or would it still be UID=0 as its way of punting on unexpected input? And, if it did choose to use UID=7, what would happen if the particular machine did not have that user in /etc/passwd?
How's this for consistency--you don't even know for sure what bad behavior systemd might take for the invalid input.
One more thought. Does systemd require that its service files be owned by root and not be world-writable? My guess is no. |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Mon Jul 03, 2017 5:50 pm Post subject: |
|
|
followup tick w.r.t. Systemd handling POSIX compliant usernames
https://github.com/systemd/systemd/issues/6259
| Quote: | systemd is not part of POSIX, and we have no intention to make it so. And yeah, POSIX mandates a couple of things, but Linux and its distributions tend to implement POSIX only where it suits them, and in different variations. In systemd we use Linux interfaces and expose Linux semantics, and only prefer POSIX if there are equivalent POSIX and Linux interfaces of the same concept.
|
instaclose
interesting /. post about these 2 bugs (as well as the dns issue...)
https://it.slashdot.org/comments.pl?sid=10813029&cid=54734407
| Quote: | Not a Lennart critic in general (I usually defend systemd) but I think the GP has a point here.
- The first bug was closed immediately despite systemd treating what Lennart considers an error (debatable) in the worst way possible - escalating a process to root privileges when the user is clearly stating it shouldn't.
- The second bug is an attempt to say "OK, we'll play your game, if you're saying that's correct behavior because of {another issue}, then let's state that {another issue} is also a bug because that's not right either.
In both cases Lennart has immediately closed the ticket without waiting for discussion. He may or may not have reasonable reasons for initially opposing the tickets (he doesn't in the first ticket's case, he absolutely doesn't - root privileges because a username (which you're not even going to bother validating) doesn't look right?! - which is what the GP is complaining about.
This is, frankly, horrifying. systemd is a key part of the GNU/Linux infrastructure, and it exists for a reason: to remove the reliance on shitty, fragile, shell scripts that were all-too-easily made insecure through ignorance or haste. Those who develop it must, absolutely must, listen to and take seriously security concerns. Closing two tickets in a row, immediately, without discussion, concerning a major privilege escalation, still worse because of logic that ultimately boils down to "The user should be smart enough to know some username rules that some developer somewhere pulled out of their arse and which only one or two tools actually enforce", is ridiculously incompetent. |
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21602
|
| Posted: Tue Jul 04, 2017 2:22 am Post subject: |
|
|
| helecho wrote: | | Hu wrote: | | Ignoring unexpected mandatory directives is wrong. |
Is that the case? |
Yes. In my opinion, any directive not specifically and clearly marked as optional is mandatory. To do otherwise is to say that parsing of the configuration file changes meaning depending on the version, and possibly the configured features, of the consuming tool. This is a recipe for confused users. Confused users are bad. Confused system administrators are dangerous.
| helecho wrote: | | Hu wrote: | | Ignoring expected but ill-formed directives is wrong (taking, for the sake of generosity, systemd's definition of ill-formed, rather than the well-argued well-formedness definitions proposed in this thread). |
Maybe the systemd design allows it? |
Based on the excuses offered in that thread, clearly, yes, systemd's design allows this. This does not make it a good design nor an intuitive one.
| helecho wrote: | | In my mind, the systemd developers should work (communicate) with other developers to solve this problem. |
What other developers misunderstand anything here? The problem is that the configuration parser as shipped disagrees with the common understanding of the configuration file by end users. This is mildly annoying on its own, but becomes a severe problem when combined with the design that unacceptable directives are ignored (and, as far as I know, users cannot set any system-wide option to force unacceptable directives to be a hard error) in a way that allows systemd to take an action different from the intuitively expected result. Failing with a hard error and refusing to run the service at all would count as not taking action, and is (in my opinion) perfectly acceptable here. If the file is security-sensitive (it is), and the file is not valid (systemd's parser says it is not), then failures should be hard errors. Anything else is dangerous.
| miket wrote: | | Actually, my guess is that systemd would try to run that service as lp (or whatever UID=7 is on that machine). |
I picked that name specifically because Github user UgnilJoZ discussed trying it. UgnilJoZ expected UID=7, but reported that systemd chose UID=0 for that test case too, despite specifically creating an account with UID=7 to probe if systemd would use that account instead.
| miket wrote: | | How's this for consistency--you don't even know for sure what bad behavior systemd might take for the invalid input. |
Indeed, and since it is an officially unsupported use case, there is (as far as I know) no guarantee that future versions of systemd will choose the same result. A maintainer might change it to use UID=7 as you describe, or to pick one of the other choices I outlined above.
| miket wrote: | | Does systemd require that its service files be owned by root and not be world-writable? My guess is no. |
While a valid concern, I am less worried about that. Aware administrators have known for a long time that world-writable configuration files are a huge danger, and are unlikely to knowingly create that situation because they know it is dangerous. They may not know that systemd's User= handling has these semantics, and so may knowingly install a service file that, under the semantics advocated in posts here, would be safe, but is unsafe under the semantics used by currently shipping versions of systemd. |
|
| Back to top |
|
|
R0b0t1
Apprentice
Joined: 05 Jun 2008
Posts: 264
|
| Posted: Tue Jul 04, 2017 7:15 am Post subject: |
|
|
| Hu wrote: |
| helecho wrote: | | In my mind, the systemd developers should work (communicate) with other developers to solve this problem. |
What other developers misunderstand anything here? The problem is that the configuration parser as shipped disagrees with the common understanding of the configuration file by end users. This is mildly annoying on its own, but becomes a severe problem when combined with the design that unacceptable directives are ignored (and, as far as I know, users cannot set any system-wide option to force unacceptable directives to be a hard error) in a way that allows systemd to take an action different from the intuitively expected result. Failing with a hard error and refusing to run the service at all would count as not taking action, and is (in my opinion) perfectly acceptable here. If the file is security-sensitive (it is), and the file is not valid (systemd's parser says it is not), then failures should be hard errors. Anything else is dangerous.
|
I am very interested in other projects which make use of systemd's response to this. There are starting to be more and more problems where it looks like systemd is squarely in the wrong, even to people who otherwise support systemd. |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Tue Jul 04, 2017 3:11 pm Post subject: |
|
|
You know what is really good with sh scripts?
You don't depends on Pottering to fix any and do it yourself, and it's like raising your stupid badly broken sh script security by like 200% |
|
| Back to top |
|
|
tld
Veteran
Joined: 09 Dec 2003
Posts: 1816
|
| Posted: Tue Jul 04, 2017 6:46 pm Post subject: |
|
|
Don't even get me started about all this FUD regarding the horrors of shell scripts. Even in the slashdot post that Naib quoted (where the guy is in fact very critical of how this one was handled) he says "systemd is a key part of the GNU/Linux infrastructure, and it exists for a reason: to remove the reliance on shitty, fragile, shell scripts that were all-too-easily made insecure through ignorance or haste.".
According to who? What the HELL does that even mean? More importantly does it mean that you're better off inserting the functional equivalent of the Windows OS...the epitome of shitty and fragile written with the most clueless ignorance out there...between the kernel and everything else?
Even Redhat doesn't believe any of that shit, and anyone paying attention knows as much.
Tom |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo Chat
