SoylentNews is people
SoylentNews
Submitted via IRC for TheMightyBuzzard
A bug in Linux's systemd init system causes root permissions to be given to services associated with invalid usernames, and while this could pose a security risk, exploitation is not an easy task.
A developer who uses the online moniker "mapleray" last week discovered a problem related to systemd unit files, the configuration files used to describe resources and their behavior. Mapleray noticed that a systemd unit file containing an invalid username – one that starts with a digit (e.g. "0day") – will initiate the targeted process with root privileges instead of regular user privileges.
Systemd is designed not to allow usernames that start with a numeric character, but Red Hat, CentOS and other Linux distributions do allow such usernames.
"It's systemd's parsing of the User= parameter that determines the naming doesn't follow a set of conventions, and decides to fall back to its default value, root," explained developer Mattias Geniar.
While this sounds like it could be leveraged to obtain root privileges on any Linux installation using systemd, exploiting the bug in an attack is not an easy task. Geniar pointed out that the attacker needs root privileges in the first place to edit the systemd unit file and use it.
[...] Systemd developers have classified this issue as "not-a-bug" and they apparently don't plan on fixing it. Linux users are divided on the matter – some believe this is a vulnerability that could pose a serious security risk, while others agree that a fix is not necessary.
See, this is why we can't have nice init systems.
Source: http://www.securityweek.com/linux-systemd-gives-root-privileges-invalid-usernames
(Score: 5, Informative) by Anonymous Coward on Tuesday July 04 2017, @01:47AM (30 children)
Excuse me linking to that green place, but ACs there nailed the core of the problem, of which this bug is just another symptom:
https://it.slashdot.org/comments.pl?sid=10813029&cid=54733511 [slashdot.org]
https://it.slashdot.org/comments.pl?sid=10813029&cid=54733623 [slashdot.org]
https://it.slashdot.org/comments.pl?sid=10813029&cid=54733449 [slashdot.org]
Long live to the resistance: BSDs, Gentoo, Devuan, Slackware and any other small or big FOSS project not bending over to the power games.
(Score: 2) by Azuma Hazuki on Tuesday July 04 2017, @02:02AM
Modded up and thank you for linking this. It's eye-opening, in the way that sitting on a cactus is, and about as painful.
Dammit all, greed turns everything into its slaves, like Jabba the Hutt with a million undressed Princess Leias on chains made of stock options.
I am "that girl" your mother warned you about...
(Score: 2) by Thexalon on Tuesday July 04 2017, @02:24AM (8 children)
I'll put it this way: It's always been clear to me that whatever Poettering's motivations, they weren't technical in nature. If they had been technical in nature, he wouldn't have gone out of his way to make his stuff not work with what already existed.
Take logging, for instance. Let's say I wanted to introduce a new binary logging format for some reason, that I wanted all system-level software to use. Should I:
A. Write something that (1) is a drop-in compatible replacement with existing widely-used logging tools like good old syslog that converts the input to the binary format and writes that to the file, (2) converts that binary file into the text formats we all know already with vim plugins and such so we inflict as little pain as possible on existing log-processing tools, and (3) has additional bells and whistles and gongs that makes this conversion all worth it.
B. Write something that uses a different kind of interface than all of the existing tools use, and demand that every daemon be changed to do things my way.
Poettering took option B, and there was no obvious technical reason for him doing so.
One other aspect of this particular bug that jumps out at me is that Poettering seems to be indifferent at best towards the concept of a "user" in Posix-based systems: He doesn't believe in sudo, su, or any similar kinds of tools. If you don't have the concept of user-based privileges, then privilege escalation bugs don't seem like a big deal, I guess. My guess is he runs his own boxes as root, which is why he doesn't notice the issues that causes or the reasons why not giving everybody root is a very good idea.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 2) by Azuma Hazuki on Tuesday July 04 2017, @02:27AM (4 children)
It occurs to me that Poettering's approach is basically how a Windows user would have written Linux programs. That is not a nice thought.
I am "that girl" your mother warned you about...
(Score: 2) by Thexalon on Tuesday July 04 2017, @02:31AM (1 child)
FTFY. After that point, Windows had concepts like users, privileges & permissions, and a whole lot of other very useful concepts that Unix had had for decades, but Poettering doesn't seem to care for.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 0) by Anonymous Coward on Tuesday July 04 2017, @05:49AM
That may be true, but I still have to run (¹allegedly) current commercial code on Win7 boxes which requires admin rights to work, try them as normal user? all sorts of weird BS happens or it just fails to run.
I still occasionally get 'bitten' by this BS with the occasional weird edge-case 'works-as-admin-but-not-as-user' snafus with Windows software, and we're not talking about just 'cheap' software having this problem, one of our expensive CAM packages has only just (just, in this case being in the past two years) gotten to the point where it no longer requires to be run as an admin user to work properly and it now runs without issue as a normal user, whereas, in the past, running it as a normal user meant that it might work 90% of the time, but then horribly fail on some operations...
The point is, while Windows does 'understand' these concepts, there's a hell of a lot of reused Windows code which doesn't, and programmers out there who still don't.
He is, indeed one of the Knights who say NIH!
¹ I say 'allegedly', I'm of the opinion that the code is exactly the same and only the version number has been changed just to make it look as if the damnable thing is still being developed..
(Score: 2) by Runaway1956 on Tuesday July 04 2017, @07:26AM (1 child)
Mmmm. That's scary to even think about. Your Windows user is likely to import DLL files for use as libraries. And, Microsoft would probably let him get away with it because embrace, extend, extinguish. Never mind that DLL's wreck anything or everything in existing libraries.
(Score: 2) by Azuma Hazuki on Tuesday July 04 2017, @07:53AM
A DLL is the Windows equivalent of a .so and in theory should be no more or less harmful all else being equal. We're long past "DLL Hell" aren't we? Now the problem is what's *in* the .dll files...this Linux Subsystem for Windows isn't even a solution looking for a problem, it's a shambling undead mess given an assassination mission.
I am "that girl" your mother warned you about...
(Score: 2) by kaszz on Tuesday July 04 2017, @03:13AM
Found another good post:
https://it.slashdot.org/comments.pl?sid=10813029&cid=54733555 [slashdot.org]
(Score: 1, Interesting) by Anonymous Coward on Tuesday July 04 2017, @03:16AM (1 child)
Text logs are fine, just add another file with pointers or any other helper metadata new tools can need. Similar to BSD vipw and pwd_mkdb handling and checking text and binary files so they always valid, easily "grepable" (text ones) or fast via API/ABI (bin ones), in sync and simple to recover if something goes wrong.
Bonus: the text log files can be set to append only (see chattr(1)). Then set owner to something except the logger process, and the group to logger process so it can
writeappend. Magic: now modification or deletion of past logs needs root or whatever owner the file has, so comprossing the logger is not enough.But you know, defense in depth is hard to grok. Another level would be shipping copies of logs to a different machine, and both local and remote would still use this append-only trick. But for standalone machines the append-only method would be an improvement.
(Score: 2) by Thexalon on Tuesday July 04 2017, @05:27PM
The point is, even if you accept that journald is useful (an open question), they're doing it wrong.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 2, Troll) by unauthorized on Tuesday July 04 2017, @02:50AM (12 children)
My experience is exactly the opposite. As a non-admin, the only arguments against systemd I regularly see are "muh unix philosophy", "it's a corporate conspiracy", "ZOMG binary logs", "it's the established truth so shut up" and "LP sucks balls".
Incidentally, the AC comment you link falls within these categories.
(Score: 4, Insightful) by Azuma Hazuki on Tuesday July 04 2017, @02:54AM (1 child)
They're not wrong though, and as someone who *does* do admin stuff (though nothing that involves fucking around with unit files or shell scripts), I can tell you I *really* do not like the systemd way. It almost feels like Powershell, which I hate with all my heart, and it has the same corporate "not for you to know, skeptic!" attitude to it as Windows, almost.
OpenRC works. It solves the issues in SysVInit which, yes, had problems. SystemD isn't a bad idea in theory but its practical realization is a disaster.
I am "that girl" your mother warned you about...
(Score: 4, Informative) by digitalaudiorock on Tuesday July 04 2017, @02:39PM
I'd say it's way more than almost, from the binary logs to the whole "nothing simple can ever be good" mindset it seems indistinguishable from the Windows approach to everything. Check out this [dns-oarc.net] regarding how systemd-resolved handles DNS queries:
How do they not see the potential to send your computer back to like 1990 due to slow DNS response? No reason to be concerned with, you know writing things that "work" "well". There seems to be an actual disdane for the simple an elegant frankly.
(Score: 0) by Anonymous Coward on Tuesday July 04 2017, @03:23AM (6 children)
You must have missed all the technical analysis posted when systemd started to push around.
I will mention just one: monoculture. That creates a stagnant enviroment, and when the issues hit, everything falls down. Now try to justify how a systemd monoculture is great.
(Score: 0) by Anonymous Coward on Tuesday July 04 2017, @05:06AM (5 children)
Linux is a monoculture. Look at AIX, the BSDs, macOS, QNX, Solaris, all have their own kernels. But every Linux distribution uses the Linux kernel.
You want to accuse systemd of being an init monoculture when Linux already is a kernel monoculture.
(Score: 2, Insightful) by Runaway1956 on Tuesday July 04 2017, @07:33AM (4 children)
"every Linux distribution uses the Linux kernel"
No, not exactly. I run the Liquorix kernel most of the time. You're going to argue that Liquorix is just the Linux kernel with some crap tweaked. And, that, in and of itself, makes it different. Whichever kernel I am running, it doesn't behave precisely like the kernal that Linus uses on his machines. My kernel has different compile flags from anyone else, I can enable or disable security features, I can leave out features that I consider to be irrelevant or insecure. Just change a few use flags, and your kernel is quite different from any other kernel in the world.
If you said that "most Linux distributions use the Linux kernel", you would be much closer to correct. Maybe you should download all the distros, and compare their kernels. Most will be alike, but not all. And, again, just because I'm using a distro, doesn't mean that I'm using the kernel that was packaged with it.
(Score: 0) by Anonymous Coward on Tuesday July 04 2017, @06:37PM (1 child)
^ found the Technical Thug
If you're going to argue that you don't have a monoculture because you can hack your kernel, then you can hack systemd also. The premise in the subject line is invalid, and the topic of discussion is moot.
Don't like how systemd Gives Root Privileges to Invalid Usernames? Fix it yourself, Thug!
(Score: 2) by Runaway1956 on Wednesday July 05 2017, @12:08AM
The argument against systemd seems to run more along the lines, "systemd is, in and of itself a hack, and a solution searching for a problem that doesn't exist". I'm not really on either side of that argument. I'm the eternal skeptic, who saw little need for systemd, but was willing to give it a try. But I keep hearing more and more arguments against systemd that make sense. Now, we have a potential security flaw that makes systemd even less appealing.
Further, there are a number of posts that indicate that systemd is more of a political solution to corporate problems, than it is a software solution to init problems.
(Score: 3, Touché) by gidds on Tuesday July 04 2017, @08:45PM (1 child)
If you're not running the Linux kernel, how can it be a Linux distribution??
[sig redacted]
(Score: 3, Interesting) by Runaway1956 on Wednesday July 05 2017, @12:02AM
Alright. I thought, "Fair question." Then, I thought, "No, actually, that's not just a fair question, it's a good question."
I guess I'm comparing Linux to Windows, which is a true monoculture. You take whatever Microsoft offers, and that's it. And, Microsoft intends for everyone to upgrade to Windows 10, and all older kernels and versions are to just die off. Proprietary is proprietary, and that side of the computing world is as monoculture as possible.
With Linux, many tweaks are documented. You can compile your kernel to be as mathematically precise as humanly possible, or you can compile it with much looser parameters. Linus and his people do, as you suggest, develop in a path, with a vision, and the Linux world mostly follows along. A quick search you may find interesting, or not - https://duckduckgo.com/?q=is+linux+a+monoculture%3F&atb=v63-6__&ia=web [duckduckgo.com]
The thing about the Linux community, is that a heretic can openly distribute whatever hacks he has made to Linus' kernel. There are no secretive forums, operating under threat of discovery by Linus and a horde of lawyers. A developer can claim to have created a "Better Linux Kernel", and flaunt his work openly, for all the world to see, and use. https://liquorix.net/ [liquorix.net]
And, it hasn't taken me very long to alter my own viewpoint a little. Doing a quick search comparing BSD kernels to Linux kernels leads to several discussions - I'll just throw the search out here, and you may dive in, or not, as you wish - https://duckduckgo.com/?q=BSD+vs+Linux+kernel&atb=v63-6__&ia=qa [duckduckgo.com]
You may make an argument that all Unix-like kernels are part of a monoculture, I suppose. With Unix, Ma Bell created a pretty damned good operating system. And, all of the "best" OS's tend to emulate Unix. You tell me - does that make it a monoculture, or not?
(Score: 2, Insightful) by Anonymous Coward on Tuesday July 04 2017, @04:02AM
Fine, as not-mechanic, you have no issue with mechanics having to dissassemble the full engine to check a small filter. It's cheap anyway.
High logic there, the issue doesn't affect you directly, then it doesn't matter for anyone (like mechanics that like to be preventive), or even you down the road. Good luck when the fucking filter clogs and you get a huge bill because that cheap part failing cascades into more parts going bad and the engine needs a full replacement. Or the engine fails and you get run over (just in case anybody wants to play the "I don't own a car" card).
You say that just as WannaCry, and family, is hitting multiple Windows versions all over the world. Monoculture sucks. Stupid complex design sucks. Hidding problems sucks. Decades of multiple OSes, but specially old UNIX, BSD (wars) and (the birth of) Linux have proved it. Starting by the propiertary ones, inlcuding those that provided source but didn't allow changes. Which is just what the comments about talk about, RH gives you the source but good luck changing it the cryptic mess.
(Score: 1) by khallow on Tuesday July 04 2017, @12:01PM
(Score: 2) by Thexalon on Tuesday July 04 2017, @05:57PM
The argument amounts to: After all this effort, what's been accomplished is replacing possibly-complex shell scripts that work with really complex C that doesn't always work.
For example, I have rendered a systemd-based box unbootable by unplugging the USB mouse that it expected to have. That isn't the correct behavior: The correct behavior, which other init systems do just fine, is to bring up the box with everything but the mouse, at which point I can do something useful.
And the "LP sucks" arguments have to do with a repeated pattern of serious and significant bug reports getting a routine response of "WONTFIX - not a bug". On critical system software, that is unacceptable.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 3, Informative) by kaszz on Tuesday July 04 2017, @03:18AM
Aha so it's Oracle vs Red Hat that is behind this.
Oracle has already been noted for being deceptive assholes in areas completely unrelated to Linux. So this stinks a long way.
Please... please.. make your software if( environment == Oracle or RedHat ) then die("Fucking shit");
(Score: 2) by Snospar on Tuesday July 04 2017, @07:47AM (5 children)
I still don't understand why Debian, and others, were so quick to jump on the Red Hat bandwagon and make the change to systemd. They've pulled a huge number of distros into this corporate fight where I thought that one of Linux strengths was the diversity of distros and in the case of Debian the democracy of large numbers of developers making reasoned choices. From a long term Debian users point of view they seemed to dive into systemd before it was even ready for prime time (I remember various supporting tools weren't even present when they first jumped). I still don't know WHY Debian would behave like that - they don't have Oracle pissing on their chips.
Huge thanks to all the Soylent volunteers without whom this community (and this post) would not be possible.
(Score: 2) by Azuma Hazuki on Tuesday July 04 2017, @07:58AM (2 children)
You and me both. I had high hopes, early on, that Debian would provide a sort of anti-RHEL bulwark and be a major force for non-systemd Linux. Essentially, I was hoping they'd rally the rest of the Linux world behind them and then everyone would say in a very loud voice "Okay RedHat, you do your thing, and certify your users on it, but that's YOUR thing."
Instead, their capitulation essentially gave over almost the entire Linux world to the RHEL way. I am almost maudlin-grateful for Gentoo, Devuan, Slackware, and the shiny new Arch-OpenRC ISO and repo on Sourceforge which I just finished installing not 2 hours ago.
Unfortunately, with Debian gone this way, *buntu and Mint are also inevitably being dragged along. I really do think Linux as we all knew it died with systemd, and all to fuel RHEL and Oracle's dick-measuring contest it seems.
And the worst part is, taken in vacuum, *that makes the systemd crew the good guys by comparison.* Arrrrgh.
I am "that girl" your mother warned you about...
(Score: 2) by Snospar on Tuesday July 04 2017, @08:20AM
I'm really hoping that Devuan gathers momentum and becomes a great success. Naive perhaps, but if they can keep fighting the systemd contagion as it touches more and more aspects of Linux then hopefully more users and developers will start to switch over. Who knows, maybe we will see *buntu or Mint based on Devuan in the future!
I know we have Gentoo, Arch, Slackware, etc that have managed to stay systemd-free but there are many who are very comfortable with the Debian way.
Huge thanks to all the Soylent volunteers without whom this community (and this post) would not be possible.
(Score: 1) by pTamok on Tuesday July 04 2017, @12:23PM
I too "had high hopes, early on, that Debian would provide a sort of anti-RHEL bulwark and be a major force for non-systemd Linux".
I was very wrong.
I don't know if Devuan has the scale needed. I hope it has, but the early signs are not good.
(Score: 0) by Anonymous Coward on Tuesday July 04 2017, @04:53PM
They wanted to ship Gnome as the default desktop.
Gnome depends on systemd-logind unless you want to patch to shim, and one can just ask Canonical how well that works.
systemd-logind in turn depends on systemd-pid1 to handle all things cgroups.
Basically Debian, for all its presence in the Linux community, do not have the manpower to go up against the code churn of Fedora/Red Hat.
End result is that these days whatever goes into Fedora eventually ends up being the de-facto standard for the Linux ecosystem.
(Score: 2) by Thexalon on Tuesday July 04 2017, @06:03PM
1. Because the pro-systemd people gamed the vote quite intentionally.
2. Poettering & friends were and still are deliberately breaking otherwise working userspace software to make systemd appear to be more and more a requirement for a Linux system, to the point that Gentoo and other anti-systemd distros have to patch things to not require it.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.