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.
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.
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.
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'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:
The process turns a request for binary DNS data into into XML, feeds it into the sytemd/dus ecosystem, which turns it into binary DNS to send it to the forwarder. The binary DNS answer then gets turned into XML goes through systemd/dbus, then is turned back into binary DNS to feed back into glibc. Apart from errors in this process, like last year's CVE on cache poisoning attacks, this means the systemd people need to very actively maintain their code whenever a new feature or RRTYPE is added to the DNS protocol. Maintenance and bugfixes is not systemd's strong point. This itecture is overly complex and unneccessary.
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.
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.
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.
"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.
^ found the Technical Thug
SITUATION: OS upgrade.
TECHNICAL THUG: Reads source code of new release, takes only what he likes.https://www.gnu.org/fun/jokes/know.your.sysadmin.html [gnu.org]
SITUATION: OS upgrade.
TECHNICAL THUG: Reads source code of new release, takes only what he likes.
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!
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.
If you're not running the Linux kernel, how can it be a Linux distribution??
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?
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.
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.