'Severe' Systemd Bug Allowed Remote Code Execution For Two Years (itwire.com) 551
ITWire reports:
A flaw in systemd, the init system used on many Linux systems, can be exploited using a malicious DNS query to either crash a system or to run code remotely. The vulnerability resides in the daemon systemd-resolved and can be triggered using a TCP payload, according to Ubuntu developer Chris Coulson. This component can be tricked into allocating less memory than needed for a look-up. When the reply is bigger it overflows the buffer allowing an attacker to overwrite memory. This would result in the process either crashing or it could allow for code execution remotely. "A malicious DNS server can exploit this by responding with a specially crafted TCP payload to trick systemd-resolved in to allocating a buffer that's too small, and subsequently write arbitrary data beyond the end of it," is how Coulson put it.
Affected Linux vendors have pushed out patches -- but the bug has apparently been present in systemd code since June of 2015. And long-time Slashdot reader walterbyrd also reports a recently-discovered bug where systemd unit files that contain illegal usernames get defaulted to root.
Affected Linux vendors have pushed out patches -- but the bug has apparently been present in systemd code since June of 2015. And long-time Slashdot reader walterbyrd also reports a recently-discovered bug where systemd unit files that contain illegal usernames get defaulted to root.
Time for tar and feathers? (Score:4, Insightful)
Anyone?
Re:Time for tar and feathers? (Score:5, Interesting)
Besides the author who suggests with the title that the bug resides in systemd itself rather than a project included under the systemd umbrella that's disabled by default on most distributions?
What a load of bollocks. (Score:5, Insightful)
The design of systemd is that they all adhere together. Claiming this is somehow not systemd is only slightly less silly than claiming it's not systemd because it's in one of the source files not called "systemd.c".
Re: (Score:3, Interesting)
Tarring and feathering would indeed be good -- especially that Lennart as usual insta-closes an obvious and nasty security bug[1] as "non-bug". And when presented with standards documents, he says they don't apply to him [github.com]. Seriously, can someone buy this guy an "Unix for dummies" book?
While we don't exactly suffer from a dearth of kooks, this particular kook enjoys having his employer promote his masterpieces even when totally inadequate. The world would be so much better without systemd, PulseAudio and a
Re:Time for tar and feathers? (Score:4, Insightful)
Followed your link, and interestingly:
poettering locked and limited conversation to collaborators 23 hours ago
He's a real team player
Who the fuck are you?! (Score:5, Insightful)
Tarring and feathering would indeed be good -- especially that Lennart as usual insta-closes an obvious and nasty security bug[1] as "non-bug". And when presented with standards documents, he says they don't apply to him [github.com]. Seriously, can someone buy this guy an "Unix for dummies" book? While we don't exactly suffer from a dearth of kooks, this particular kook enjoys having his employer promote his masterpieces even when totally inadequate. The world would be so much better without systemd, PulseAudio and avahi.
Actually nevermind, here's root access.
Re:Time for tar and feathers? (Score:5, Informative)
It was closed because it has already been discussed at length here:
6237 [github.com] is about running services as the wrong user, 6259 [github.com] is about usernames allowed by POSIX but not by systemd.
Do you actually have an argument against his logic here? As in a good reason to follow POSIX rules in this case when Linux in general, which is what systemd follows, does not.
Linux doesn't even know about usernames (just uids), you may at most discuss the behaviour of a particular userland program. And every program I know of (a bunch was tested by someone on IRC) except systemd handles ones starting with a digit correctly, as POSIX prescribes. For some reason, adduser (but not, eg, useradd) dislikes creating new accounts with such a name but all it takes is specifying an option when it relaxes the check from names merely discouraged to ones that are illegal only. No other account creation program complains.
The other reason is that you have to accept any legal external input, and input allowed by the standard is certainly legal. And you need to handle illegal input as well, at the very least by returning an error rather than giving full root access.
any actual argument beyond "he immediately closes bugs I think are obvious!"
That's Lennart's usual response to anything that's not obvious to him. Most of us try to at least research a bug or ask the reporter to explain.
MS Windows attitude (Score:5, Insightful)
It's things like this that remind us that Lennart is even now still a newbie who thinks in terms of MS Windows. The tool that could create such a username is any text editor, which is something nearly every sysadmin and nearly any long term user of *nix could have told him.
Re: (Score:3, Insightful)
any actual argument beyond "he immediately closes bugs I think are obvious!"
The solution is left as an exercise
Serious users do not consider this a problem
I don't know what the name for this fallacy is, but if nothing else, it's an Appeal to Authority by proxy. It shuts down discussion by implying that if one were at the same exalted intellectual plane as the claimant, then there would be nothing to discuss. And that, by implication, if you consider that there actually is something to discuss, you are inferior.
Given in response to an honest question, it is an attack on the querent, and, as such, intellectual bullying.
Comment removed (Score:5, Insightful)
Re:Time for tar and feathers? (Score:4, Insightful)
One of us has this backwards... It looks to me like in both cases Lennart is saying that systemd follows the Linux standard, not POSIX.
What Linux standard? The LSB? POSIX is the only other standard involved, and Linux tends to follow POSIX in spite of the many protestations that Linux is not POSIX.
Comment removed (Score:5, Insightful)
Re: (Score:3, Insightful)
And again, it's not the huge security issue some people make out that it is because in order to create a user with a name starting with a digit and then create a service starting as that user, you have to have root anyway.
true, but - with people downloading packages (rpm/deb/whatever), what if that package contained a unit file with such an ID ? off to root it goes. So does that means a admin after installing a package needs to examine the unit files even if from a trusted source ?
Bugs happen and since systemd is open someone found it and it may very well have been fixed by now. If systemd was proprietary, at this point maybe only the (three letter) orgs would know and keep it a secret. So the development model worked any
Re:Time for tar and feathers? (Score:5, Informative)
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.
Re: (Score:3)
Since systemd doesn't get to dictate valid usernames, this isn't a reasonable argument.
It's also just outright wrong because Unix does not have any concept of system users, nor does Linux. Only one user is inherently special, and that user has UID 0. Every other user is used exactly as you use it. Nothing prevents you from assigning a password to one of those "special" users and logging in to it, any more than anything prevents you from creating another user account with a locked-out password and using it in the same way as the "system users".
Re: (Score:3)
I'm asking you to find out if you know, not to find out the answer, which I already know without having to look anything up. They don't have passwords or expiry, and they're in a low UID range. That's it. It's a convention, and if you completely ignore the convention then everything still works anyway. If you create a system-like user with a higher UID, or if you give a system user a password, the system does not give a fig; It does not malfunction, nor does it attempt to prevent it even slightly.
Neither UN
Re: (Score:3)
Re:Time for tar and feathers? (Score:5, Informative)
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."
Re: (Score:3)
Perhaps this:
~# adduser 0day
adduser: Please enter a username matching the regular expression configured
via the NAME_REGEX configuration variable. Use the `--force-badname'
option to relax this check or reconfigure NAME_REGEX.
Wait a minute...
~# adduser --force-badname 0day ... ... ... ... ...
Allowing use of questionable username.
Adding user `0day'
Adding new group `0day' (1001)
Adding new user `0day' (1001) with group `0day'
Creating home directory `/home/0day'
Copying files from `/etc/skel'
Enter new UNIX password:
Re: (Score:3)
Could you give a reference to the rule you are referring to? I don't know where to look it up and determine that:
"The rules for Linux user names say they must not start with a digit"
Re:Time for tar and feathers? (Score:5, Insightful)
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.
Re: (Score:3)
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.
Re:Time for tar and feathers? (Score:4, Insightful)
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"?
Re:Time for tar and feathers? (Score:5, Funny)
Re: (Score:3)
But feather probably would Considering how ancient the most recent version of Feather Linux [wikipedia.org] is, chances are good that this might actually not use systemd.
Re: (Score:3)
tar and feathers?
$ man feathers
No manual entry for feathers
mmm...
The problem with systemd (Score:5, Insightful)
That's a problem with Systemd. It's a pretty decent idea with a sub-par execution and a crappy way of dealing with an inherent problem.
Idea: centralized place to optimize startup, management and interconnectivity of all kinds of services.
Problem: some services in their standard form don't quite fit that model.
Solution: let's rewrite them and include as parts of systemd.
The crap part: while the originals were made by experts in that field, the replacements are made by a group of wannabe experts on everything ever, some with overinflated ego. This results in seriously inferior code replacing old 'tried and true' solutions.
At this point, the only real solution I can see is making a fork of systemd, banning the current systemd creators from participating in it, and trimming it to size. If a service doesn't quite fit systemd, work on systemd until it fits, don't rewrite it!
Re:The problem with systemd (Score:5, Informative)
"a fork of systemd, banning the current systemd creators from participating in it, and trimming it to size. If a service doesn't quite fit systemd, work on systemd until it fits, don't rewrite it!"
That's not a bad idea - meanwhile, Poettering's response (presumably): "Systemd is working as expected. This is a flaw in {bind/whatever}. Bug closed."
Re: The problem with systemd (Score:5, Insightful)
And, security problems + no logs = even bigger problem. Even if he doesn't get why logs are important for security, I wish he would get why they're needed for troubleshooting. It sucks managing a lot of special snowflake servers with systemd since so often error messages don't make it to the journal.
Re: The problem with systemd (Score:5, Interesting)
Indeed, I already had two remote servers lost over this very issue. I never had systems fail before systemd, either. The first was one that consistently failed to shutdown, but no logging and nothing in the journal made it impossible to ever discover exactly why. Another failed to boot, and it is equally unclear why. It really is rather crappy.
Re: The problem with systemd (Score:5, Insightful)
Lately I had a flaky service and to get it working I ended up wrapping the daemon in a shell script, and had systemd call that shell script instead. I still had to fight with systemctl because apparently it knows better than me how long a daemon should take to start before giving up, but I managed to get it working *in spite* of systemd.
Now I have a Docker-first policy and for the most part it's to avoid dealing with systemd.
Re: (Score:3, Informative)
If a service doesn't quite fit systemd, work on systemd until it fits, don't rewrite it!
Part of the appeal of the systemd is that it minimises the idiosyncrasies of all the different tools. You don't have to rewrite the services, but fitting them to systemd is reasonable. For example, udev was not rewritten, just integrated.
originals were made by experts in that field
Whatever made you say that? There are no mandatory security audit, secure coding practices, mandatory code reviews, qualification certificates or anything like that in free software. Some of it is even insecure by design (I'm looking at you, X.org). systemd will get rid of
Re:The problem with systemd (Score:5, Insightful)
"Some of it is even insecure by design "
So because all software has bugs we should just say: "Meh, who cares if systemd is bloated, has monumental feature creep, an author with a serious ego problem who doesn't like fixing them and it replaced an init which, while a bit crusty did what it said on the tin, because, well, systemd." Right?
Wrong. Systemd, is a poor idea, poorly implemented in a project thats poorly managed. Quite why redhat are in thrall to the arrogant little twerp in charge is anyones guess.
Re: (Score:2, Troll)
Re:The problem with systemd (Score:5, Interesting)
Systemd, is a poor idea, poorly implemented in a project thats poorly managed.
Yup.
Quite why redhat are in thrall to the arrogant little twerp in charge is anyones guess.
I don't know how he got a foot in the door, so all I have is my long-distance high-level. The short and sweet is "politics", and he's red hat's useful idiot in their war with oracle.
red hat tried to tighten up their business model by splitting red hat-the-distro into fedora and RHEL. The centos guys forced red hat to release RHEL anyway because GPL. oracle then copied the whole thing verbatim, minus the branding, and called it "unbreakable linux". This allowed them to piggyback on red hat's hard work including their knowledge base. Which is why red hat put that thing behind a paywall. So oracle is doing their level best to eat red hat's lunch and using red hat's own work to do it.
So, what can red hat still do? Well, they can become more proprietary, which is where systemd comes in. No, it's not closed source, but it sure is wilfully, deliberately, and very gratuitously, incompatible with everyone else. So if a big enough party like red hat pushes it into the market, then the rest (*cough* debian *cough*) feels they have to follow suit. That means a big boon in control for red hat. And that's what it ultimately is about.
Of course, you have to have some sort of story of benefit for people to go along with the gambit. But for many the sort of fine-grained control you lose by going systemd wasn't that important anyway, for the good and simple reason that throwing more virtualisation and more hardware at it seems faster and so more cost effective. It's the same sort of reason why virtualisation and massive hardware is so popular in the windows world. The big gain for red hat sure isn't technical, it's political. You can see this in the fact that many rebuttals to technical complaints about systemd are entirely non-technical. Any time a technical argument ends up full of bullshit and personal attacks it really isn't about the technical merits any more.
I doubt poettering himself understands his role in this, seeing his grasp of architecture, code quality, and so on, so that makes him a "useful idiot". He sure does have the personality to pull it off, though. Incompetent arrogance does go a long way, with the right backing.
And, of course, once they get off the ground, bad ideas are hard to kill.
Why does Red Hat allow damage to its reputation? (Score:5, Insightful)
"Systemd is a poor idea, poorly implemented, in a project that's poorly managed."
"... sure is wilfully, deliberately, and very gratuitously, incompatible with everyone else.
"I doubt Poettering himself understands his role in this, seeing his grasp of architecture, code quality, and so on, so that makes him a 'useful idiot'. He sure does have the personality to pull it off, though. Incompetent arrogance does go a long way, with the right backing."
Systemd, and the poor way it has been presented, had been damaging to Red Hat's reputation ("Dead Hat"). Why did Red Hat management allow that? Is it because Red Hat makes money providing consulting services, and wants Linux configuration to be difficult so that the company will make more money?
Re:The problem with systemd (Score:5, Insightful)
Because "the crap part" is not what is written on the box. Systemd *appears* attractive. The idea is neat. The promise is tempting.
Including systemd in your distro is like preordering No Man's Sky.
Re:The problem with systemd (Score:4, Insightful)
There is no one on the internet who uses Linux who hasn't heard a hate-filled rant calling systemd a piece of shit.
Every comment section, of every website. Reddit. Slashdot. Mailing lists.
So you're welcome to come up with a new reason for why everyone uses it "even though it sucks." But your reason of "nobody knew it would suck" is complete bullshit.
Re:The problem with systemd (Score:5, Interesting)
The reason is simply every commercially used Linux distro switched to it. We're stuck going along for the ride.
Re: (Score:3, Interesting)
Because systemd is now a hard dependency of the Gnome desktop, which a lot of distros want to ship. There were some interesting shenanigans involved in getting that through too - initially the Gnome developers insisted this was no bid deal because logind (the part they required) didn't actually depend on systemd and could be used seperately. Ubuntu did this for a while. Then Poettering declared that actually this was never supported, Ubuntu were idiots for doing it, and it would be broken shortly. Ubuntu re
Re: (Score:3)
Re: (Score:3)
Re:The problem with systemd (Score:5, Interesting)
Systemd is abysmal for users, but less work for distro maintainers.
For example, service files are drastically shorter than init scripts (albeit unlike them, not universal unless you fall back). This could be easily fixable by using a common library, but that'd be a bit of actual work!
On the other hand, systemd is a complete and utter abomination for sysadmins. When sysv-rc (not sysvinit, these parts are modular!) does something wrong, it's a matter of a single line of shell to hack it for your particular use case. On the other hand, when you want systemd to do something Lennart didn't think of, there's no resource (unless you really want to dig through the source of the huge blob, debug it, recompile, install, then do the whole thing again on an upgrade or security update). Just two examples: 1. the usual idiom of mount --bind a filesystem with complex sub-mounts so you can rsync/etc it in peace, 2. degraded mount of btrfs RAID.
Seriously, an init implementation that conflicts with something as basic as RAID, has no place on any non-toy machine.
I for one wear both hats, of a distro developer and a sysadmin. But it's the latter what I get paid for, thus sorry, no systemd anywhere I can shake a shit-covered stick at.
Re: (Score:3)
Systemd, is a poor idea
Which is why all the technical leads of various distributions couldn't wait to adopt it...
Not quite. It was more a case of "Do we want to include Gnome in our distribution or not?"
Re: (Score:3)
The crappy part is the centralized place to optimize startup.
Even Windows isn't this bad (Score:5, Interesting)
When I first read about systemd I thought it was a knock off of the NT service control manager [microsoft.com]. Except on Windows, that's all it does. It controls services. It starts and stops them. And manages dependencies. And that's it. It doesn't take over the fucking world and try to control everything in the OS. I think this is where systemd lost its way. It's a sad day when we look to Windows as the example of "does one thing and does it well" and not the whole fucking kitchen sink.
Re:Even Windows isn't this bad (Score:4, Interesting)
Systemd's extra promise was *optimization* of startup.
It was meant to be achieved through creation and binding of sockets: Service X must wait for service Y to start and create a start up, because X needs to bind to a socket Y creates. It won't be using that socket in a while yet, but it can't initialize without that socket present.
What systemd does is create that socket so that Service X can bind to it right away, and proceed with startup, and once Y arrives at the point of creation of the socket, it's bound to the socket Systemd created. There, instead of sequence of complete startups of services, which is lengthy, you have only sequence of socket binding, which is fast, and parallel startup, which is fast too.
This is a neat idea which breaks upon meeting the reality.
Because not everything uses sockets. Not everything can start up with the socket merely present, some need it for real right away. Not everything is structured the way systemd envisioned it; some applications aren't just monolithic executables, but e.g. lengthy shell scripts repeating hundreds of calls to a given executable with different parameters (e.g. iptables). They just don't fit that idealized framework.
And so, the framework does what a framework with overinflated ego author does. Including the crap part.
Re:Even Windows isn't this bad (Score:4, Interesting)
That is doable but very cumbersome. You'd need a central makefile for the whole system, and adding or removing anything would require a rebuild.
Gentoo isn't exactly everyone's favorite, and this would make Gentoo's level of problems pale by comparison.
Note it's not just about ordering the startup, it's about fulfilling all the requisites with 'dummy' interfaces until the provider of what the 'dummy' is for starts up, then transparently substituting. "Want to write logs but syslog still didn't start? We provide a queue that will store your logs until syslog... uh, wait, syslog can't do this that way. Welp, fuck syslog, here's our journald, and it has binary log files which are superior because we say so."
I don't quite see how just makefiles could solve that.
OTOH I really don't see the problem with delaying the startup by literally several milliseconds to let syslog start, instead of ripping it off and replacing with something everyone hates. Simply put, some optimizations are definitely not worth the cost.
Re: (Score:3)
Note it's not just about ordering the startup, it's about fulfilling all the requisites with 'dummy' interfaces until the provider of what the 'dummy' is for starts up, then transparently substituting. "Want to write logs but syslog still didn't start? We provide a queue that will store your logs until syslog... uh, wait, syslog can't do this that way. Welp, fuck syslog, here's our journald, and it has binary log files which are superior because we say so."
Put this way it sounds like systemd is to init what GUICE is to Java. Lets create some stub interface for all services that doesn't actually do anything until we can spin up whatever it is that's supposed to go there. It can be very powerful to do this sort of dependency injection in user space and have things like circular dependencies resolved automagically. I haven't had many issues with systemd on any of my personal systems, but I may be a over 3 sigma from the mean.
Though I do have to question the logi
Re:Even Windows isn't this bad (Score:4, Insightful)
The problem is not having to wait a few ms for syslog to startup, the problem is that syslog have dependencies (like i.e access to a file system) that needs to be up before it can be started and thus everything that logs before that is missed unless something else does it.
And journald is not something that "everyone hates", some people here on Slashdot does yes, but there are lot's of people out in the real world who uses it and prefers it to the old syslog. I was myself quite sceptical when journald was announced with binary files but now that I've used it for some time I do realise that there are things it does and that it does well that would be just impossible or extremely complicated to do with the old syslog text format (i.e that the journal catches all output from stdout and stderr and joins it with the syslog output by adding the unit name in the meta-data, or that you can search for all logs produced by a special unit without accidentally get logs from other applications mixed in due to them matching the same grep pattern).
Re: (Score:3)
(i.e that the journal catches all output from stdout and stderr and joins it with the syslog output by adding the unit name in the meta-data,
if I want all the output from a daemon, I can have that without systemd. I just stuff it into /var/log/.
or that you can search for all logs produced by a special unit without accidentally get logs from other applications mixed in due to them matching the same grep pattern).
If I want that functionality with syslog, I just log that group to its own file. Then I can search just that file to get only logs from that group. Done and done. Though actually, the only Linux machines I have running 24x7 are actually using busybox's syslogd, which I don't think has that functionality. I don't need it, so why bother to have it? The systems in question are very low-memory.
Re:Even Windows isn't this bad (Score:4, Informative)
My guess is it's the sunken cost fallacy - in the beginning they didn't realize just how many flaws their idea had, and once they got the thing running initially, they would not admit the failure (ego problem).
Re:The problem with systemd (Score:5, Informative)
At this point, the only real solution I can see is making a fork of systemd, banning the current systemd creators from participating in it, and trimming it to size.
There are problems with that idea:
* Red Hat is backing Systemd and this is the only thing Lennart seems to work on. You'll be in the quagmire of always trying to catch up on new shitty features and broken compatibility.
* Systemd was 250K+ LoC last I checked
* Systemd's source code is poorly documented at best.
* Systemd has a overly clever design that makes it difficult to grok.
I'm not saying that Systemd shouldn't be replaced, I'm saying that you need to discard the original.
Re: (Score:2)
So the product is open source but not open spec.
Re: The problem with systemd (Score:5, Interesting)
It's worse than that. The community didn't have any say in it, it just got rammed down everyones throats; its revealed that linux has started to follow the cathedral model as vendors like Redhat gain more and more exclusive control over it. At this point its worth asking who controls linux, the community built out of tends of thousands of projects that come together, or a few corporate entities?
Corps control Linux, not hobbyists (Score:3)
At this point its worth asking who controls linux, the community built out of tends of thousands of projects that come together, or a few corporate entities?
For a while now, the corps. Whoever is paying the salaries of developers is in control. Look at the concept of budgeting. Its not necessarily about how to wisely spend money, its also about control. Control by determining how much in the way of resources get allocated to some idea. To prioritize idea. To ensure that work is following the plan developed by senior management, not some plan developed by a consensus of engineers.
Didn't some analysis of commits a while back show most Linux development is corp
No, its not a pretty decent idea (Score:5, Insightful)
"centralized place to optimize startup, management and interconnectivity of all kinds of services."
Sorry, thats not how its done in Unix. We don't want a huge monolithic application as init since that brings a huge attack surface to the most important process in the OS, not to mention a bug in a service that doesn't belong there potentially bringing down the entire system.
Re:No, its not a pretty decent idea (Score:4, Insightful)
We don't want a huge monolithic application as init since that brings a huge attack surface to the most important process in the OS
Perhaps we need to get rid of Linux kernel as well. But seriously, to reduce the attack surface, just disable unused services (the article even points out that Debian has systemd-resolved disabled by default). systemd is modular.
Re: (Score:2)
Disable unused services? Like DNS in this case? Good luck using your computer to browse the web without it.
Re:No, its not a pretty decent idea (Score:5, Funny)
systemd is modular.
Yes, so modular [troubleshooters.com].
Integrate the Linux kernel (Score:4, Funny)
>> Perhaps we need to get rid of Linux kernel as well.
Nooo, that's a bit over the top.
We only need to integrate the Linux kernel into Systemd.
Re: (Score:2)
Re: (Score:3)
Re: (Score:3, Insightful)
That's a problem with Systemd. It's a pretty decent idea with a sub-par execution and a crappy way of dealing with an inherent problem.
If by "decent" you mean "spectacularly stupid, fantastically bad, terrible to depraved depths, will never work properly", then yes.
The problems with basically anything written by poettering and crew start with them being... let's be polite here, not very good with this "software architecture" thingy. Their approaches to any problem they're setting out to solve, real or imagined, are baroque, juvenile, overly complex, brittle, prone to spectacular breakage, and so is their entire everything else.
Yes, there a
Re:The problem with systemd (Score:4, Insightful)
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.
Surprised? (Score:5, Insightful)
Dupe (Score:5, Informative)
Story from 5 days ago [slashdot.org]
From all of us Linux greybeards: (Score:5, Insightful)
We told you so.
Re: (Score:2)
Re: (Score:3, Informative)
systemd is broken by design, and despite offering highly enticing improvements over legacy init systems, it also brings major regressions in terms of many of the areas Linux is expected to excel: security, stability, and not having to reboot to upgrade your system. [ewontfix.com]
Don't be dense.
Re: (Score:2)
Old News (Score:5, Interesting)
This is old news, why don't you publish that story how "Principal systemd developer refuses to acknowledge serious security vulnerability where processes that request to be run as unprivileged user, run as root because Lennyboi does NOT like them start with zeroes! And POSIX be damned, Lenny knows better!"
Re: (Score:3)
Okay, let's look at this bug.
It requires existing root access in order to create a new user. So if someone exploits it, you are already fucked.
You say it goes against POSIX. This is true, but so does Linux. So do some of the GNU tools. Somehow that's okay, because strcmp("systemd", "linux") returns a non-zero value in your mind.
What is your argument that it shouldn't be fixed in the various user account management tools rather than in systemd?
Re: (Score:3)
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
Re: (Score:3)
"0day" is not an illegal username. You don't even any need "tools", beyond a text editor, to legitimately and legally create users on Linux.
Systemd only considers it to be illegal because they don't want to bother correctly parsing and validating strings and yet still want to use a common field for string or integer input values.
Re:Old News (Score:4, Informative)
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.
not your father's least surprise (Score:3)
You must be new here. The Doctrine of the Useful Idiot is referenced these days almost hourly. Hence, you must be really new here.
In this case the "useful idiot" is the trusted repository administrator, who permits a package to be hosted from upstream because it doesn't look suspicious in any way (unless the obscure rule about user accounts with leading digits is top of mind—as if every
Re: (Score:3)
I don't know about AC, but I can name a few reasons. First, systemd is the noob, it's up to it to fit in with existing systems which may already have user names it doesn't like. Or it should at least not create an accident waiting to happen (that is, at least fail clean).
Second, any software should be liberal in what it accepts and strict in it's output. I suppose that's an argument that it be fixed in systemd AND the other utilities. Robust systems should deal in a reasonable way with illegal but not actu
Re: (Score:3)
That's not the error here, the error here is that "0day" is ignored, leaving the service to run as the default user "root". It could just as easily been "3day" or "nоbody" and the service would have run as root.
not the init, and it doesn't affect Debian (Score:4, Informative)
The summary misleadingly opens with "systemd, the init system", whereas what we're talking about is "systemd-resolved, a part of the SystemD project" (or some such -- I'm a bit vague about the capitalisation TBH).
Anyway, the point is that this bug is not in the init code.
On Debian, we don't even execute this code by default.
So, if you see red and start screaming whenever you see the sequence of characters: s y s t e m d then I'm sorry if you're still reading this, but perhaps you should consider calming down long enough to notice that systemd is both the name of the init program, and the project that also includes a lot of other bits and pieces that are not even needed quite often, and can generally be run without having systemd running as init.
Re:not the init, and it doesn't affect Debian (Score:5, Interesting)
"that are not even needed quite often, and can generally be run without having systemd running as init."
I don't think anyone is in any doubt that once systemd has the option to run a service most of the bleeting distro maintaining sheep use it. It won't be long before it becomes the default resolver on most of them.
Re: (Score:2)
Re:not the init, and it doesn't affect Debian (Score:5, Informative)
On Debian, we don't even execute this code by default.
But Ubuntu does. And the other security hole mentioned in the article does apply to Debian.
As for systemd being more than just an init: the problem lies in it replacing a large set of modular projects with an entangled blob. For example, vdev is an (experimental for now) replacement for udev that fixes a number of design problems, yet good luck using it on a systemd system.
As for running systemd without it being init: systemd-shim is dead, and it was flaky to the point of uselessness even while it lived. You need to recompile the Utopia stack to enjoy basics we used to take for granted like being able to shutdown or suspend from a GUI.
People have tried carving out pieces of systemd to use them separately, like uselessd, yet all such attempts I know of ended in failure because of systemd's blobbiness.
I expect nothing less from Poettering (Score:2, Insightful)
Remote exploits in critical system services? I expect nothing less from the PulseAudio creator.
If you're not familiar with smoke any mirrors from the SystemD PR king [0pointer.de], then perhaps these inherent flaws in his projects comes as a surprise to you. But for years a handful of people tried to put the brakes on Poettering and his cronies from hijacking Linux and turning it into his egotistical vision of desktop Unix.
We have failed.
Better distro suggestions? (Score:2)
Re:Better distro suggestions? (Score:5, Insightful)
That's easy. FreeBSD! It is POSIX, UNIX philosophy through and through, and not only completely free of Poetteringitis; it's free of all immature and incompetent vanities and warped design crazes.
One has to hand it to the systemd team (Score:2)
Remote exploitable bugs in core-Linux are incredibly rare. The systemd team is really going where nobody else has gone before. That is not a good thing at all, of course, because if you do this, you need to have excellent skills, which the systemd team most decidedly does not have. Fortunately, none of my machines or those of my employer needs to be patched, because we have banned systemd early on due to the massive KISS violation it represents. Nobody here is surprised by this bug.
The second one (Score:5, Informative)
The second 'bug' mentioned is far more crazy. The unit file mentions a user that doesn't exist (well, in tfa it is wrongly parsed, even worse), so the default action is to continue as root (instead of supplied user). And this is a good idea because... ??
Why can't this unit action just fail? Wouldn't that be far far better then just deciding to use root, this might cause all kinds of problems. I wonder which other nice surprises and default fall-back action are encoded.
Re:The second one (Score:4, Insightful)
In systemd, if a unit fails, the ENTIRE init system fails and your system boots in emergency mode.
And that is worse than allowing full escalation to root in what way?
The problem with that development team is a focus on single user laptops and desktops where it doesn't really matter if the user has full root access. They should be paddling in the shallow pool of MS Windows 10 instead of changing something people want to use for servers.
Meanwhile in Slackware land... (Score:5, Insightful)
- "Uh? There has been another issue with systemd? Really?"
- "Yeah, but anyway, never mind, we have better things to do."
- "Okay."
Slackware: no systemd, sane defaults, no weirdo patches.
Yeah, it works.
"Intellectually dishonest" (Score:5, Informative)
The last time I criticized systemd I was accused of being intellectually dishonest.
I'm not sure how being a Linux developer and sysadmin both in my personal life and as a paid employee since 1994 could possibly allow me to intellectually dishonest about any subject having to do with Linux. Dishonesty about Linux could not possibly benefit me in any way.
What I said is that systemd started out being very buggy. Admittedly, to paraphrase Linus Torvalds, they shook most of the bugs out and it works okay most of the time.
Except that systemd changed the way everything has worked for decades, and not for the better.
I could go into specific examples, but suffice it to say that virtually everything that systemd has taken over, it is doing that job poorly. Seeing why services didn't work and making them work has gone from a 5 minute job to something that can take hours. Troubleshooting system problems by looking at logs has become arduous in some cases compared to looking at /var/log/messages or typing dmesg and having your answer in 2 minutes.
systemd needs to slim down and focus on what it does well, initializing weird devices. systemd has no business monkeying around with DNS, and that is just the beginning of the list of things it needs to take a step back from.
Call me intellectually dishonest, but I've been working with Linux for 23 years now (I installed Slackware 2.0 in July of 1994 from a stack of floppy disks) and I haven't failed to learn a thing or two along the way.
Re:"Intellectually dishonest" (Score:5, Insightful)
I started with Unix in 1982.
Systemd fails many of the basic Unix concepts. Small, interconnectable tools, text log files, human readable configurations.
Re:"Intellectually dishonest" (Score:4, Insightful)
Re: (Score:3)
How are the unit files not "human readable configurations", especially when compared with the old sysv init scripts?
Because virtually all of the behavior was in the init scripts where you could read it, whereas most of systemd's behavior is in the various daemons, where you have to be able to understand the code to understand what it's going to do when you feed it a simple unit file.
Of course, in order to understand what an init script does, you have to understand shell scripting; but shell scripting is a central feature of Unix which you should understand anyway as an admin, no matter what you are doing with it. Users a
Is there a replacement for systemd? (Score:3)
This is a serious question. Yes I know there's init, but systemd must have something going for it, otherwise it wouldn't be the default of just about all distros on the planet. ... Faster boot times come to mind.
So, is there an alternative to systemd since everybody seems to be bickering about it? What about a Linux that boots in under 10 seconds? If systemd is so shitty, what's holding people back from developing a system that is better and faster?
Thanks for any input on this.
Re: (Score:2)
Re: (Score:2)
the fuck are you talking about? what does politics have to do with shitty software development?
Re: (Score:2)
Re: (Score:3)
Re: Now it becomes clear... (Score:5, Insightful)
See, this is textbook example of systemd apologists having zero clue about the software they praise.
Is the INIT part of systemd and PROCESS MANAGEMENT "simply better"? Maybe, probably (with the exception of it ignoring invalid values instead of failing to start, like this 0day issue).
But how on gods goddamned earth is reinventing a DNS recursor, which btw is not RFC compliant (per the developer's OWN words it might NEVER be compliant because that idiot has no clue what resolvers really are), any BETTER?!?! It is not better. It is far worse. They're reinventing something they do NOT properly understand and in the process introduce NEW bugs and insecurities, and reinvent OLD bugs that proper resolvers have gone through in the past decades.
Maybe if you would LEARN what systemd really is inside, maybe then you'd see it's a steaming pile of shit that has LONG gone beyond being an init replacement.