Don't panic, but Linux's Systemd can be pwned via an evil DNS query Systemd, the Linux world's favorite init monolith, can be potentially crashed or hijacked by malicious DNS servers. Patches are available to address the security flaw, and should be installed ASAP if you're affected. Looking up a hostname from a vulnerable Systemd-powered PC, handheld, gizmo or server can be enough to trigger …
Let me provide an analogy. You know, xpdf frequently had code execution vulnerabilities found in it and ultimately was removed from Gentoo in 2014 when another one resurfaced and became the last straw:
https://security.gentoo.org/glsa/201402-17
"Description: Multiple vulnerabilities have been discovered in Xpdf. Please review the CVE identifiers referenced below for details.
Resolution: Gentoo has discontinued support for Xpdf. We recommend that users unmerge Xpdf: # emerge --unmerge "app-text/xpdf"
After that, there's no more xpdf in Gentoo. They use mupfd instead. I hope systemd meets the same fate, the sooner the better. Flushing toilet water icon, please.
I use systemd on all the servers I manage, out of choice. I refuse to set up non-systemd server-setups any more, it is just so vastly more pleasant to work with than the alternatives.
So, for me personally, when systemd came along, it solved all the problems I ever had with system initialization. What most systemd critics consider "bloat", I consider necessary complexity to solve a complex problem generically. You can say what you want about Poettering, but he actually realized what the problems with system initialization were and provided a working solution. I could go on for hours, but this should be a good summary.
A lot of the pushback against systemd - merited or not - is because a lot of people in charge of little parts of the bazaar have seen their pet projects cast aside by the major distros and taken over by the systemd devs. In a world where street cred is a big force in motivating people to contribute to open source being maintainer of 'x' where 'x' is part of each and every linux distro out there and then to see 'x' taken over by systemd in a fairly rough manner without any kind of co-operation between the old maintainers and the new kids on the block there are bound to be a lot of ruffled feathers. But that's not technology, that's just ego.
I find amusing that no one here is asking why systemd-resolved was introduced, or what problem was it intended to solve, read this post:
https://lists.ubuntu.com/archives/ubuntu-devel/2016-May/039350.html
Everything that is wrong with systemd is down to it M$ style design, it doesn't belong on professional systems anymore than windows does.
Yes, you gain ease of use and fast setup but at the cost of security and stability with the obvious result that you open yourself up to security problems that occur because you let someone else make the decisions you thought weren't as important as getting up and running.
The pushback against systemd is because it takes what were independent systems and rolls them into a tightly coupled monolith. The independence of those prior systems was their greatest strength - the more independent those systems are, the less opportunity there is to bring down the entire OS by crashing one of those systems.
systemd can claim to be modular all it wants; the fact that you can take down the entire OS via the init with a malicious dns response is a fucking travesty in this day and age. It's the sort of thing that even Windows left behind at the turn of the century.
Can you explain to me your rationale for believing that "you can take down the entire OS via the init with a malicious dns response" when systemd-resolved is quite clearly a separate binary from that running as init and has also dropped its privileges and is running as a non-root user?:
# ps | grep init
1 root 7824 S {systemd} /sbin/init ldb
1108 root 2696 S grep init
# readlink -f /sbin/init
/usr/lib/systemd/systemd
# readlink -f /usr/lib/systemd/systemd-resolved
/usr/lib/systemd/systemd-resolved
# ps | grep systemd-resolved
359 systemd- 5816 S /usr/lib/systemd/systemd-resolved
1097 root 2696 S grep systemd-resolved
# cat /etc/passwd | grep systemd-resolve
systemd-resolve:x:231:231:systemd-resolve:/:/bin/nologin
systemd-resolve:x:231:
# cat /etc/group | grep systemd-resolve
systemd-resolve:x:231:
#
I find amusing that no one here is asking why systemd-resolved was introduced, or what problem was it intended to solve, read this post:
To paraphrase for anyone not wanting to read it: "DNS is probably too complex for you to manage, so we're adding an extra caching resolver to every machine, which simplifies certain desktop configurations".
If I'm going to be treated like a child, I expect milk and cookies at 3pm, and then a nap.
This post has been deleted by its author
I've always found it odd that systems would enable dns reverse lookups for all sorts of things where it provides no value. I don't trust DNS to give me a valid name if all I have is an IP address.
The whole thing of probing someone's network and have them look up your IP address where you then send TCP packets back to crash their name server or other application has been around since the early 1990s.
It also adds an unpredictably slow, often blocking process to whatever you're doing. There are situations where it's useful, but almost all of them are better handled in after-the-fact processing by non-privileged code.
However, there are other scenarios where this bug could trigger. For example, if you're using an untrusted network that can intercept your DNS queries.
I've always found it odd that systems would enable dns reverse lookups for all sorts of things where it provides no value. I don't trust DNS to give me a valid name if all I have is an IP address.
That's why you also look up the name to see it matches the same IP address, otherwise there's no point, in fact it's worse than no lookup at all if the name is logged instead of the IP.
The whole thing of probing someone's network and have them look up your IP address where you then send TCP packets back to crash their name server or other application has been around since the early 1990s.
That's a daft thing to say. If someones name server can be crashed this way, then it is at fault, and needs to be fixed. Nothing to do with DNS lookups, apart from maybe reducing "security by obscurity", which of course is a non-reason.
To people who think reverse DNS is a good idea, consider concepts like CNANE loops. Smart DNS servers will catch it but there are plenty of dumb DNS implementations out there. In IPv4 we could send a UDP request out and expect to get a UDP response back but now with IPv6, the packet sizes often exceed the MTU resulting in several packets. Once you get a large chunk of data back, someone at the other end might just be playing games with malformed DNS packets or even just broken DNS settings. What does you application do when you get back thousands names for a reverse lookup? What happens when each lookup results in a chain of CNAMES? What happens when the end of those chains result in hundreds of addresses that are all the same?
DNS isn't authoritative, it is informational. It is great when it doesn't lie to you. But you can't test for when it does.
ALL software has bugs, get over it.
It is precisely because all software has bugs that design decisions should be made to limit the impact of those bugs. It's like RAID, all disks are unreliable, eventually the industry twigged that the answer wasn't to make more reliable disks (even though that helped a bit) the answer was to design storage systems where disks dying wasn't a big problem.
When it comes to SW the trick is to make sure that you're not exposed to the risk of bugs unnecessarily. Design your SW so as to limit the impact of the inevitable bugs.
When it comes to SW the trick is to make sure that you're not exposed to the risk of bugs unnecessarily. Design your SW so as to limit the impact of the inevitable bugs.
It's unclear whether you think that the language should have protected the developer from risks, or that the software should have been composed of more coherent, smaller, and less tightly coupled components.
@ Tom 38
> It's unclear whether you think that the language should have protected the developer from risks, or that the software should have been composed of more coherent, smaller, and less tightly coupled components.
I think both. A traditional "init" is written in C but most of the functionality is actually in shell scripts which are invoked by "init". Now shell is messy, but at least it is not vulnerable to buffer overruns. In principle there is nothing stopping you from rewriting the shell scripts in some saner programming language (Python, Ruby, whatever rocks your boat).
Note that dividing the software in smaller blocks also means that you can use an appropriate programming language for each block.
And that's an argument in favour of a giant monolithic buggy piece of software?
Many things that systemd does are bad copies of stand-alone software with reduced functionality and/or bugs. If it were a stand-alone DNS daemon then you could easily change to another one.
Why would you even want to shove everything in the same process? If it goes down the system is hosed, if it's exploited then all functionality that systemd does is compromised.
>> If it were a stand-alone DNS daemon then you could easily change to another one.
Dude, you can just do that, systemd-resolved is a separate module.
systemd stop systemd-resolved
systemd disable systemd-resolved
systemd mask systemd-resolved
apt update
apt install dnsmasq
I guess this is the 21st century version of the peasants with pitchforks.
I cringe every time I hear someone try to deflect the storm of _VALID_ criticism that blows in when someone brings up systemd by dismissing the fact that the problem can be fixed/worked around/removed and or put back to the way it was when it was still working.
Yeah, it's replaceable, but you'd have to replace it EVERY TIME, SYSTEM by SYSTEM. You'd have to regression test ever major version upgrade to make sure it doesn't turn itself back on. You may not even have root access on the underlying system. Ever hear of cloud hosting?
There are real problems with systemd. It breaks things. If we have to fix something that wasn't broken before, THAT IS A PROBLEM. A problem that we didn't have before and we now have to fix.
@ rtfazeberdee
All software has bugs, therefore software like init, which runs as the very first process and with elevated permissions, should be kept as simple as possible.
In contrast, the systemd developers have included a ridiculous amount of functionality into the init process. (process 1). See http://suckless.org/sucks/systemd for an overview. Often for no other stated reason than to "keep the number of processes down".
A traditional init system wouldn't even contain networking code, let alone do reverse DNS lookups.
Consider that it is generally estimated that high-quality code contains one defect every 1000 lines. Consider the size of systemd, all of which is running as the privileged process 1. Weep.
"bad software has bugs" FTFY
Every person who has done any coding will have made a "hello world", the ones who progressed will have made certain that it worked before moving on, so clearly it is possible for all competent coders to write without bugs. Mathematically that is a lot of good code that proves that not all software has bugs
The excuse that the complexity of coding is greater than any other human endevour is also clearly false as computers are fundementally simple in operation. The computers never get confused only programmers.
The "all software has bugs" and "computers are so complex we should be excused for our mistakes" are Urban myths i.e both false but have been repeated so often that people actually believe them true. M$ I am looking at you
IMHO anyone who quotes either of them is either a shill and/or an incompetent.
The "all software has bugs" and "computers are so complex we should be excused for our mistakes" are Urban myths i.e both false but have been repeated so often that people actually believe them true. M$ I am looking at you
If you type with 99% accuracy that means on average you mis-type one character in every 100. With red squiggly underlines and the like you can pick up typos where the typed word is not found in the dictionary, but if you type "cant" where you meant "can't", there's a good chance you'll not pick up the typo.
Where that typo is a number in a program of a few million lines of code, each done by several people over the years, you will only find it if the typo causes a compile error or warning, or if it eventually causes a noticeable failure in the software. In some cases (eg Heartbleed or EternalBlue) those bugs can take a number of years to be noticed, because the flaw is not triggered in such a way as to cause a problem.
But there's other bugs as well, such as a condition the programmer never thinks to test for (no, you cannot test beyond your experience and beyond what is suggested to you), your code might work flawlessly on every possible situation, but someone has a single pixel in a photo that is #FFEE66 and something in your code reacts with that, and you tried a few hundred thousand colours in your testing but just not that one. It could be a slight delay in how one CPU processes commands, or a system configuration that fragments memory in some weird way, or... So many things you cannot possibly expect and test for.
When code gets beyond a few 10s of lines it becomes hard to spot typos and other bugs. Transpose a couple of digits, not have an obvious flaw at compile and testing, the bug will ship. You may never know it exists, or it may be found the day after shipping. That's why patching systems in professional-grade OS's (and software) work so beautifully, because we need to be able to fix software when someone finds something is wrong.
Theoretically it is not impossible to write perfect code in a complex program. In theory you could type every character in a couple of million lines without one typo. In reality, most humans struggle even to get to a mere 90% typing accuracy (that's one mistake in every 10 characters typed!).
That human's err is not unknown, since we know this then we can take actions to mitigate the chances of a typo being an issue.
It reminds of electronic projects from my youth and machine code programming onto an EPROM via entering the hex and manually writing it byte by byte, if you made one fat fingered mistake then you had to wipe it and start again. Whilst it was an absolute pain it was possible, with sufficent diligence and practice input errors disappeared.
Flash forwards a few decades and people are saying that it is not possible to avoid typos in a highlevel programming language which has lots of verification tools to help, from my experience if you cannot manage to avoid typos ending up in your finished code then clearly things have been made too easy for you to enter bad data. Perhaps if compilation error detection wiped your source you might learn to code without errors too.
The lessions I learned were to be certain of what your are entering and keep things small so you do not have to maintain that level of concentration for too long. Now programming is so much easier we seem to have lost the discipline and especially the attention to detail.
Bug free code is possible but why bother when enough people believe that it is not
om my experience if you cannot manage to avoid typos ending up in your finished code then clearly things have been made too easy for you to enter bad data
I referred to rates of typing mistakes in my post, and I stand by that. Sure, with experience like yours you can become much better than average at typing accuracy, but is that at the sacrifice of speed?
I don't know of any tool for entering bad data other than the keyboard BTW. Well, you could probably use some voice recog or mouse-driven interface but speed drops quite a bit there, keyboard is still the fastest way to enter words into a computer IME (am looking for decent voice stuff but little out there).
A compiler will pick up obvious errors, and may pick up a number of other errors that would still compile but there's something "not quite right", but there's a lot of stuff that can be syntactically perfect, make perfect sense to you when you read the code, but still not be doing what it's supposed to.
But you can guarantee that every number you've entered into code is right? You've never noticed that you'd accidentally transposed a couple of variables (or a variable and a constant)? Never forgotten to remove debugging stuff ( {ifdef debug..} ) wrapped around what should be a random number but you were using a constant so you could test the code? You're either one in several billion, or maybe your code isn't that complex.
BTW, I can spot a half a dozen potential grammar errors and few typos, and at least one word-choice error in your short message! :)
Getting rid of systemd won't stop buffer overruns.
No it won't be getting rid of buffer overruns, but something as critical to system operation as systemd simply should never be placed in a position where it can be exposed to this kind of attack, or any kind of remote attack. That's not an "I hate systemd" statement, that's a basic security for kindergarten level lesson.
Fixing these issues is going to be a giant game of wack'o'mole where there is simply no need to expose yourself to danger in the first place. This isn't just a bug it's a fundamental design flaw.
No, the reason to hate systemd is that Linux already has a bunch of DNS resolvers that are pretty secure. You can pick your favourite.
But systemd must use its own, special, freshly-written one. Because, systemd. So that decision obliges most Linux distros to host a single, new DNS resolver. That is broken.
Unfortunately, this has been the way with systemd for a while. New way of doing things becomes The One, True, Only Way before the code is actually fully finished and tested. And, if bugs are found, or pre-existing features are removed, it is your fault for trying to do whatever you used to do before.
So, yeah, hate. Just been embarrassed in front of a customer by the COMPLETELY UNNECESSARY change to the way that partitions (especially swap) are mounted. Oh, and did you know, that if your machine ceases to boot because of a systemd config error, you can't fix it in the recovery console?
Bah!
"the article makes it clear that use of the systemd resolver isn't compulsory. Yet. At least not if you use Debian."
this is true. my Debian 8 'beater' box [which I'm using to test changes/updates to a customer web site before implementing them on the actual site] has systemd on it, unfortunately, but isn't using resolved for anything significant (or at all, for that matter).
/etc/resolv.conf is a regular file with the expected text-based contents in it
I think you may be able to DISABLE systemd-resolved by making /etc/resolv.conf a static file, rather than a symlink to the /run/systemd/whatever file. Can anyone confirm that?
This post has been deleted by its author
> Unfortunately, this has been the way with systemd for a while.
> New way of doing things becomes The One, True, Only Way before the
> code is actually fully finished and tested. And, if bugs are found, or
> pre-existing features are removed, it is your fault for trying to do whatever you
> used to do before.
That's not unique to systemd, that's Linux in general. Every time I upgrade my Mythbuntu setup to a new release I have to learn at least one new way of doing something that was working perfectly well before. I think they like to call it progress. I just call it a pain in the arse but it seems unfair to single out systemd alone for that treatment.
> That's not unique to systemd, that's Linux in general. Every time I upgrade my
> Mythbuntu setup to a new release I have to learn at least one new way of doing
> something that was working perfectly well before.
That's Linux for you. Everything is about the shiny-shiny. If something is broken, don't fix it - write a new one! OSS was broke on linux... replace with alsa!
udev, devd, hal, not hal - there is no discipline in the design, it's all just thrown together. You should check out the BSDs for stable and sensible changes
Glad, but not surprised, to see that the average Reg reader is more resistant to the systemd Koolaid.
One extra point that hasn't been hammered home yet is all of the compatibility breaking changes it introduced. I can't think of a better example of change for changes sake (Not that the bootloader cleanup, that was badly needed).
Today I was wrestling with a VM that handles tftp services for updating switch and phone firmware. I typed ifconfig to confirm one of it's ip addresses. OOPS some self righteous @$$hat decided that systemd is so awesome that we should all type "ip addr show" now, because you know reasons. Want to tail -f a log file that's been in the same place since 1970? Guess what, the same genius couldn't even provide a symlink or command alias, so now off to google to figure out you need to use "journalctl" now, because they apparently haven't heard of "man" or "info" either. They have apparently not worked on many embedded systems either, where you wind up serial porting into a tiny distro that has had virtually everything stripped out of it but you find that the graybeard that set it up still left you vi so you can fix a config file on the fly.
What burns me isn't that people tried to push for a better boot process forward and ended up with systemd. It burns me that after all the problems it causes they still haven't fixed it, and we haven't replaced it. Systemd as it stands is an objective failure. Perhaps not catastrophic, but a failure.
It should be fixed, or it should go away.
The fact that the people who came up with it are thin skinned and and find it precious isn't a reason to put up with it. The fact that it seemed to solve THEIR problems does not mean they should ignore the problems they cause for a huge part of the community. Like the IPv6 fiasco, they have lost sight of their objectives, and failed to deliver an effective replacement. Like IPv6 they lost track the core problem they were supposed to solve(Boot process improvements instead of ipv4 address exhaustion) along the way, and started fixing things that weren't really broken (like banning NAT in IPv6, or bypassing the existing system DNS resolver in systemd, or screwing with logging system.
This should of gotten stopped in it's tracks before it got merged into the distros. In hindsight we'd ask...
What does this change improve? It slightly improves the boot process by introducing more deterministic boot behavior.
What are the drawbacks? Huge tracts of non-audited code that haven't been tested at scale, impacting huge sections of the OS that aren't strictly involved with the boot process. Scrapping backwards compatibility with previous version Linux, and current versions of BSD and OSX. Every programmer of every app will have to read, understand, and then assess and possibly implement changes to their application, even if it didn't suffer under init.
Well, gee that sounds like a terrible deal, lets not do that.
Glad, but not surprised, to see that the average Reg reader is more resistant to the systemd Koolaid.
If ever a post deserved someone making a botnet to upvote, I think this would be it. Alas, I cannot do the botnet, but I can do a beer icon and my one single upvote.
Much gracias for a well-written post!
I typed ifconfig to confirm one of it's ip addresses. OOPS some self righteous @$$hat decided that systemd is so awesome that we should all type "ip addr show" now, because you know reasons.
I don't think the move to using the "ip" command in place of "ifconfig" is anything to do with systemd. The ip command gives more control over the network config than ifconfig, but ifconfig is easier to use in most simple cases. RHEL7 has taken the the dumb (IMHO) decision not to include ifconfig (and all the other Berkeley network commands) in the default "minimal" configuration. For the most part ip and ifconfig happily co-exist.
Surely if systemd had it's way it would be illegal to configure any network device without using NetworkManager. NM together with systemd is an even more challenging environment. There is a reason why most OpenStack howto docs start off with instructions on disabling NM. You don't have to go as far as OpenStack to discover why, any system which doesn't just manually deploy VMs is likely to have major issues.
On the other hand NM can be useful on laptops.
"Getting rid of systemd won't stop buffer overruns. This vulnerability is handy for the systemd haters but the real problem here is coding in a language that allows overruns to happen, isn't it?"
Yes C with or without the ++ allows for for naughty code but the original idea back when it was a System Engineer was that the person writing the code knew wholistically what he was doing.
It isn't really the languages fault if the person using it makes decisions based upon unreasonable assumptions rather than knowledge
"the real problem here is coding in a language that allows overruns to happen, isn't it?"
The real problem behind the popular opinion you have repeated here is young programmers who learned to program in languages that handle memory management for them, and consequently have not developed the mental discipline necessary to do it themselves.
So systemd provides with an optional module systemd-resolved to do dns caching, Ubuntu uses it to replace dnsmasq, there is a bug in systemd-resolved which affects a small number of distros, notably Ubuntu 17.04 for which a patch does exist...
Oh noes, the end of the world!
A security vulnerability isn't reason enough to hate anything. I am skeptical of systemd because it goes against the Unix philosophy of a series of simple modules that each do one task really well, which is part of what has made Unix and Unix-like OSes endure for decades, but that's the neat thing about open source: No one forces any of the other projects or distro maintainers to use it. Most of them seem to be headed that way, though... in some cases, it's because the upstream has already made the decision, but within that upstream bunch are a lot of people that have a lot of passion for their projects that know a ton more than I do about Linux, and they are going systemd and PulseAudio.
Personally, I have never had any of the audio difficulties PulseAudio is supposed to cause, and Mint seems to be the same whether I select a systemd boot or an Upstart (though it does boot a little faster with systemd; Windows 8.1 trounces them both, even with the Windows fast boot disabled... not that I really care much, as I reboot pretty rarely).
It's pretty clear that Microsoft is dedicated to destroying Windows, and I will never migrate to 10 if it even somewhat resembles the mess it currently is (and it's pretty clear that MS is dedicated to making sure it remains an unusable crapfest), so Linux clearly is it. The local OS won't even matter if everything moves to "the cloud" and webapps as the prognosticators claim. I just hope to have a usable browser after Mozilla's upcoming suicide later this year so that I can use all that stuff. Firefox and FF derivatives are the only browsers in existence for the PC that I consider usable at the moment (there are none on Android, as far as I am concerned).
> Personally, I have never had any of the audio difficulties PulseAudio is supposed to cause,
> and Mint seems to be the same whether I select a systemd boot or an Upstart (though it does
> boot a little faster with systemd; Windows 8.1 trounces them both, even with the Windows
You're coming from a windows background - even a kludge-fest like pulseaudio and systemd will seem better by comparison
(there are none on Android, as far as I am concerned).
As I get time, I'm playing with OpenVPN and Pi-Hole (installed on a Mint 17/KDE media machine atm but I'll hopefully finish my replacement server (under Devuan) this weekend and move it there). The idea being that I have the OpenVPN Android client connected, and with Pi-Hole blocking all the nasty domains it knows of (>111,000 at present), that makes the browsing on Android reasonably safe, and also protects your other activities (such as banking etc) as the VPN encrypts traffic between the device and home.
So far it seems to be working well, and I'm using Opera on the VPN - Firefox refuses to run on the tablet and Chrome is just icky, especially as I discovered when I tried to connect to my webserver using my vpn's url (vpn.myregisteredomain.co.nz) Chrome would only open a search page; you can only enter URL's that Google allows into chrome, if they don't "know" or allow the URL you cannot visit it! I've had the domain for some years, and various subdomains on it as well.
Anyway, putting this here as something for you (or others) to think about. Took a few minutes to set up the vpn and a few more to chuck Pi Hole in. If anyone wishes to talk more in-depth either hope I re-check this thread, or talk nicely to El Reg about contacting me directly.
I have literally never managed to get PulseAudio working. Not once, and I have tried four times (because Alsa is a pain to configure, and because Pulse allegedly offers a BlueTooth audio sink that I covet).
All these installs are on headless machines, which is the problem as doing anything Pulse without it being owned by a user logged in at the console is discouraged and (it seems) untested. FWIW I've been using Linux as my primary OS since 1995 (Redhat Mothers Day FTW). If I try to bend this OS to do my bidding, it almost always works.
PS. Seconding Kiwi's sentiment above, AC has it nicely summed up.
I'm less interested in hating it than simply getting rid of it, as a very pragmatic matter of necessity, not personal bias. It's a serious liability, as has just been clearly demonstrated, yet again, not merely because it has "a bug", but because this level of exposure should never be allowed anywhere near an init system, and certainly nowhere near something running at PID 1. That's sheer lunacy, a fundamental design flaw that cannot simply be "patched".
It's beyond time that the blinkered Poettering cabal faced the reality that Systemd is an overreaching abomination, created for highly dubious reasons, that is doomed by virtue of its own convoluted design to cause more problems, and of a far more serious nature, than it purports to solve.
Unlike the Poettering cabal, the Unix philosophy is not a fanboi club vying for popularity, it's the advocacy of solid engineering principles in the realm of software, principles that the aforementioned fanbois have completely abandoned. This incident should serve as a warning to them that they need to grow up and start thinking more like engineers, and less like children.
I've been using linux since v2 and love it. It was the system which allowed me to get stuff done.
It is still the *nix-like OS which also gives me Steam, but now I'm playing with freebsd for servers and I really love that.
It is a joy to use and it has a simplicity which I think linux has lost.
You can also get Steam working on FreeBSD, but it's a bit of a pain. It runs reasonably well through WINE, under FreeBSD, depending on your graphics adapter (I found that a laptop with elderly Intel graphics ran the excellent Freedom Force vs The Third Reich without issues, but bombed out on many other games).
The best reason to use FreeBSD?
Well - it was the reason why I started to use FreeBSD. I do have 2 linux machines still - the elderly, much updated, currently running Ubuntu 14.04[1] mail/web server and the small VM that's running the Ubiquti wifi controller.
[1] I keep trying to re-create it in FreeBSD, but 20 years-worth of upgrades and tweaks is hard enough to reproduce on a newer linux box, let alone throwing in the changes for FreeBSD. I will do it when the pain gets big enough. Which it's starting to - the VM is starting to core-dump on a regular basis.
Actually, as a dedicated Linux user I can say in all seriousness that I'd probably vote for Windows before Systemd (which, let's face it, actually qualifies as an operating system at this point, albeit undoubtedly the worst operating system of all time).
I'd probably vote for Windows before Systemd
Even I would vote that way!
A big part of the problem is that many of SystemD's promoters cannot see the issues with it, such as how to read a corrupted binary log file when the system is acting up and the information to tell you what is wrong is contained in said FUBAR'd (literally!) binary log file.
Slackware.
The first ever linux distro I ever used. 0.99pl15 I think.. Some time in the 90's, on a 386sx25 with an 80MB ATA hard drive and a 330MB ESDI drive also attached (lying on the floor beside it in fact - it was a full-height drive and the computer was in a fairly small desktop case..
This post has been deleted by its author
Programming blunder was accidentally introduced... hmmm sure... pass me my tin foil hat please... but anyway, why exactly did we ever agree to let this crap into our servers??? Oh wait, because RedHat and some talent-less pulse audio dev screamed the loudest that we should... shame on the spineless bunch at Debian for enabling this farce... But hey at least my laptop now boots 200ms faster than before... totally worth it. </sarcasm>
Put in an ssd - my laptop shows me the grub thingy and then flashes a couple of times and is ready to go. Even without systemd I've not worked out why I turned it on yet let alone sat down comfortably,
I could get grub to go quicker but I really cant be arsed.
shame on the spineless bunch at Debian for enabling this farce..
To be fair, if you want to use Gnome then you pretty much have to also use systemd since it's tied pretty closely together.
Me - I would have dumped Gnome as the default UI and given it as an option for those who don't care about the internals.
... I dislike the very concept of systemd. In my opinion, it's one of the worst ideas that the FOSS world has come up with in the last thirty years.
HOWEVER, this is just a bug, people. All code has bugs. Some are worse than others, true. And this one's pretty bad, also true. But it's just a bug. It'll be patched. Save your negativity for valid reasons, not simple bugs, or you'll just come off sounding childish.
The point is that someone, and we all know who, has used their corporate position (i.e. control of the Gnome project) to force a big pile of code onto the rest of the Linux world, and has made the classic mistake of making it do too much, for no good reason. For example, what earthly reason is there for an init system to be providing a dns reverse lookup service?
By unnecessarily replacing lots of existing working code with a lot of new code, it's inevitable that there's a shit load of vulnerabilities. These are going to take decades to find and fix. And because of the unnecessarily wide scope of systemd and it's privileged position in an OS, bugs are potentially dangerous.
And because a ton of scripted code has been replaced by a ton of C code, arguably there is more classes of bug (like buffer overruns) to be worried about.
This has been a backward step in system security. It will be a long time before we can trust it. There are very large groups of bug hunters out there who have every intention of using them for malicious purposes, and systemd is great for them. Even if Pottering can point at an empty list of issues for systemd, that doesn't mean there are no security bugs.
"And because a ton of scripted code has been replaced by a ton of C code"
ISTR a rubric which went something like:
Never do in C that which you can do in shell.
Never do in shell that which you can do in awk.
Never do in awk that which you can do in sed.
Never do in sed that which you can do in tr.
"someone, and we all know who, has used their corporate position (i.e. control of the Gnome project) to force a big pile of code onto the rest of the Linux world"
worth pointing out: at some point in time, a couple of years or so before systemd was excreted into the linux realm, Micro-shaft "invested" in the gnome project. Embrace, Extend, Extinguish anyone?
a bit of supporting history can be seen here:
http://www.theregister.co.uk/2013/06/03/thank_microsoft_for_linux_desktop_fail/?page=2
and there's also the whole mono and C-pound thing. I'm certainly _NO_ fan of ANYTHING that hauls in mono as a dependency. but it's unfortunately growing, most likely by being artificially propped up from the side by Micro-shaft and various C-pound/.Not fanbois.
I propose that Micro-shaft has injected "its way of doing things" into the Gnome project, which also ended up in systemd, as well as Gnome 3. It is evidenced by the monolithic nature of systemd, the "2D FLATSO" influence in the Gnome project, and possibly an increase in mono-dependent or C-pound-dependent things...
(none of that is good for Linux)
Well said Jake, but it is precisely systemd's size, complexity and poor architecture that attracts the bugs, and will continue to do so for the foreseeable future. The systemd project has shown unbelievable naivety in being unaware of this basic fact of software engineering, don't you think?
It reminds me of the Unity debacle. Design a system which, for sound reasons, is disliked by many. Foist it on people. Don't listen to anybody. Carry on for years. What an awful waste.
Unfortunately most anti-systemd trolls are childish and couldn't code their way out of a paper bag
No. A lot of people had already written a ton of perfectly good code, which RedHat/Pottering then consigned to scrap heap using their control of another key project to force everyone else to follow suit, replacing it with a pile of code that has repeatedly been shown to be full of security flaws like this one.
RedHat / Pottering might be able to code their way out of a paper bag, but their strategic decisions have put everyone including themselves inside several thick hessian sacks tied at the neck. It's going to take a long time to get out of the sacks.
GNOME may as well be closed source.
Anyone through about re-doing systemd in Rust?
@rtfazeberdee
I notice that just about every post you've made here is to slag off people pointing at systemd's flaws, without providing explanation.
I can only *hope* you are a troll, because if you're a systemd supporter then you are justifying everyone's assessment of systemd's Microsoft-like culture and fanbase. Attack opponents. Push territory. Tribal Conquest, without remorse or mercy.
No-one but no-one was forced to use it by anyone, it proved itself technically and functionally otherwise it would have been consigned to the annuls of history.
Ah I see, so are the constant rumbling storm of complaints based solely on all of those people voluntarily choosing to switch over to systemd and deciding they don't like it?
"you should just manually re-partition and customize the defaults of every system from now on" isn't a valid argument. The fact that some parts of the larger systemd project can be replaced isn't a valid rhetorical counter to the problems that were caused when several of the distros strong armed them onto the rest of community.
And as to it's technical merits, it was a noble effort, but seven years at sea and it's listing rudderless and in irons, and the crew has abandoned trying to right her. Instead they are madly adding more weight to the hull by adding new "features" instead of grabbing a bailing bucket and combating the problems in the bilge.
If you don't like that image try a simpler one:
If you don't like hearing people complain about your cooking, don't force it on their plate, just put it on the table and let those that want it take it. The fact you can throw it out isn't a reason for them to not be upset with you.
Unfortunately most anti-systemd trolls are childish and couldn't code their way out of a paper bag
Whereas all the systemd defenders are paragons of virtue who would never stoop to ad-hominem attacks eh?
Hint: Grow up. There are a lot of us hate systemd, not because of who is writing it (although their attitude to bug reports doesn't help), but because it represents the increasing windowsification of linux. Replacing simple init methods (and there are many) with a sprawling, bloated mess of dependencies and hidden bugs is not the way to go - and it would never have succeeded if it were not for the fact that it comes from Redhat and has very tight links and dependencies with Gnome.
HOWEVER, this is just a bug, people. All code has bugs.
Right, all code has bugs. However this bug is a direct consequence of putting kitchen sink + all in to init. This is the bug that most everyone who has written software and looked at systemd thought it would eventually, inevitably, get.
Is it wrong when someone is hoisted by their own petard, that we point out the crater of the explosion?
You know what else is almost everywhere and had a vulnerability in its DNS resolver? glibc. Zawinski's Law at work, at the OS level. "Every system service attempts to expand until it can resolve DNS queries. Those services which cannot so expand are replaced by ones which can."
P.S. systemd is the greatest achievement of humankind. Well, it works. Usually. Better than SysV init anyway.
The thing I find really weird is this:
systemd depends on glibc
a part of systemd, for some obscure reason, needs to do DNS lookups
systemd re-invented the wheel instead of using road-worn glibc code
I sincerely hope this is a one-off, if their policy is to re-write everything from scratch, refrain from using standard library calls for standard stuff, systemd will destroy GNU/Lunix's high reliability image.
"P.S. systemd is the greatest achievement of humankind. Well, it works. Usually. Better than SysV init anyway."
SysV init is based on a single text file with service definition. It supports automatic restarts and runlevels, so it's trivial, for example, to change over from the main HTTP server to one showing a "maintainance page". Just have 2 runlevels, one with the main server one with the other one. (or 2 different configuration files) Then switch the runlevels, and daemons will automatically be started and stopped.
It's simple and elegant and gets the job done.
That while this bug sucks, it may not effect all users of systemd with those versions.
I have many systems running systemd and not one of them have systemd-resolver active. Thus, those systems are immune even though they are running an effected systemd version.
When running systemd there is no requirement to use systemd-resolver and typically you (or your distro) will need to manually enable it.
So before you panic run:
systemctl status systemd-resolved
If disabled you'll get one of two messages depending on distro:
$ systemctl status systemd-resolved
Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; disabled; v
Active: inactive (dead)
or
$ systemctl status systemd-resolved
Unit systemd-resolved.service could not be found.
If you get either of these responses, you're safe.
"That while this bug sucks, it may not effect all users of systemd with those versions."
Thanks! A timely reminder that this stuff is written by journalists, technical journalists, but journalists all the same. Also that most commentards have headless chicken with dysentery syndrome.
"A timely reminder that this stuff is written by journalists, technical journalists, but journalists all the same."
That's right. Journalists who put this paragraph in the article:
The bug is technically present in Debian Stretch (aka Debian 9), Buster (aka 10) and Sid (aka Unstable), however "systemd-resolved is not enabled by default in Debian," according to the project's Salvatore Bonaccorso, so either you have nothing to worry about, apply the patch yourself, or hang tight for the next point release.
It helps to read the article as well as the comments.
we're to busy listening to dickhead "technical" managers running around like headless chickens over the rather minor (for those outside of Eatern Europe" NotPetya outbreak.
Our's seem have come across phishing attacks for the first time and they are ALL NottPetya apparently. Total incompetent fuckwits.
I looked at the attack vectors and went Meh.
God I hate this job (ok more like hate the people I work under).
Shame it pays so well.
Yes, but it's systemd, so there's a good chance it actually will overtake an equivalent Windows bug thread, and the level of bile will be higher. Linux fans may hate the heathen Windows users, but that's nothing compared to their loathing for the pro-systemd heretics.
You know, genuinely, I was worried when I read this. I immediately went to my laptop and checked for updates. I got even more worried when I didn't see any updates for Systemd.
But, when I sat back in the chair thinking "Shit what am I gonna do?!", it suddenly hit me.
I use Devuan.
Leaving aside why this particular bit of SW is even doing this function. If fails what seems like it should be rule #1
Never unconditionally trust input from outside your code, in size or content.
Not if it's user input.
Not if it's from removeable media
Not if it's down a wire (or a wireless link) from A.N.Other computer.
I know, this protocol is from the dawn of the internet when all the sysadmins knew each other, all played nice etc. However it's the implementation that's insecure, not the protocol.
That said this option is off by default.
So IRL who has been using it and why?
"Leaving aside why this particular bit of SW is even doing this function. If fails what seems like it should be rule #1"
Actually, I'd probably say rule #1 should be "Never make your code do something that it has no business doing in the first place". I don't need the init system to respond to reverse DNS lookup requests. No-one has ever needed an init system to do so. So why in God's name is Systemd doing it?
It's not just this vulnerability that shouldn't exist; the entire function which the vulnerability is in shouldn't. That has to be more fundamental than even not trusting outside inputs here.
Logically, the correct patch would be to remove the entire reverse-lookup component, yes? As far as I'm concerned, they can patch until the cows come home. If systemd continues to bloat itself with functionality that simply does not belong in Init, I'll be sticking with Gentoo and its perfectly adequate OpenRC.
Agreed. Most people would consider it an inappropriate choice for a capability to include in this sort of program. Although I'm sure the same could be said of various other functions in various other programs, where what should have been done was a smooth, common interface to the rest of the system.
However if you have decided to include it to begin with then being suspicious of external input (from anywhere, including stuff that is nominally coming from another program) seems like the basic precaution to follow.
Never unconditionally trust input from outside your code
I'm not sure I'd trust input from inside the code either
a) We all make mistakes
b) At some point someone else is probably going to fiddle with your code who won't understand the limitations.
That's a trickier one.
Where do you draw the line?
Your external input has gone through validation functions and you've documented all valid parameter ranges, so later devs know what they can and can't do.
You don't pass huge hundred field data structures around (used in a dozen different ways, set by a control field) because that's been known to be a complex, error prone development approach since the late 1970's.
What more can you do?
"time for you to do some much needed research into systemd"
Maybe it's time for you to realise that many of us have been using Unix and Unix-like systems for decades without systemd. Those systems have done sterling work for us and for those who've paid us over those years. We have not experienced any problems that systemd would have been needed to solve. We therefore see no more need to install systemd to our systems than, say, a mechanical apple-picker (unless, of course we were to work in the cider* industry in which case the apple-picker might well be of use).
In short systemd is irrelevant to us. If the word irrelevant is unfamiliar to you look it up in a dictionary. Systemd does nothing useful for us that its predecessor didn't do. And, by long experience, we know better than to install something more complex than it needs to be.
We do not argue from ignorance. We argue from experience.
*Mmmm- cider ->
Nope, time for you to do some much needed research into systemd because anti-systemd trolls display a complete lack of knowledge about it because they just reprint other trolls ignorant misinformation.
Ok, so I'll do my research by asking someone who obviously knows a great deal about systemd and OS's in generalm, such as your good self.
Please tell me kind sir, why does systemd - an init process - need to be doing reverse-DNS lookups? For that matter, why is it replacing su/sudo/kill etc? What benefit is there for my system in having this stuff in systemd?
As you have obviously thoroughly researched systemd and all it entails, I await your prompt explanation, and thank you in advance for the time taken to give a decent reply that will help me better understand the benefits of systemd, and the logic behind the features that have been added to it.
The spell checker in the OP's systemd word processor obviously has an undisclosed bug too.
You know, there are times when I would welcome a single system-standard spell check - as long as it came with a correction mechanism - Firefox always seems to be underlining me like a smug disapproving teacher - I'm a lazy get, point out the corrections too, dammit, doing half-a-job in only pointing out my mistakes is annoying.
But even spell checkers are often not much use on a semantic mistake.
O goody, then systemd-resolved should just work with any init, not just systemd, right?
I mean, it is not as if it would be somehow submitting untrusted network data to process 1? Clearly no need for communication with process 1, right? It's a completely independent thing.
Of course, now one could wonder why it was even necessary to replace the perfectly-functional DNS resolvers already in place, which were written by people who actually understand DNS.
Why can't they write their own for their own project? Why would init use a DNS resolver? Explain why, as you say, there are a multitude of DNS resolvers in Linux. Why is there not only one, why are there many? To cure your ignorance, you really need to do some research as to what does and what does not use PID 1 in systemd and also find out the difference between systemd binary and systemd the project, you might find some answers there .
Hush now. We understand that you like it, but your nigh-constant inclusion of personal/semi-personal attacks with every retort does not lend much to your credibility. Though the things you are saying are not invariably wrong, you come across as an abrasive prick. Flies, honey, vinegar, etc.
> Of course, now one could wonder why it was even necessary to replace the perfectly-functional DNS resolvers already in place, which were written by people who actually understand DNS.
Oooo I know this, if you go to http://suckless.org/sucks/systemd and follow the link for "pid 1 does DNS" it says:
"In contrast to the glibc internal resolver systemd-resolved is aware of multi-homed system, and keeps DNS server and caches separate and per-interface."
Happy to help.
This post has been deleted by its author
I *think* maybe the thought process was that multi-homed clients should have separate caches for each interface, which does make a little sense. (I'm interpreting the "server" portion here to be the local DNS caching resolver. Many Linux distros run one these days, with resolv.conf pointed to localhost.)
That's what I read. Supposing a machine is running TWO network interfaces (eth0 and eth1), perhaps because it's a network guard so has to be a Janus (facing BOTH internally AND externally at the same time, required of a gatekeeper). Then it would make sense that one doesn't want to contaminate each interface's DNS caches with each other since a resolution meant for one network doesn't necessarily apply to the other.
This post has been deleted by its author
What were these clowns thinking of?
Writing your own resolver when you're already using libraries that have resolver code? Stupid. I can understand not wanting to invoke another process to call a resolver, but ignoring library routines? Fucking stupid.
WTF does init need to do any DNS lookups? If it's essential then that means off-line use is impossible. If it's not essential then why do it?
These fucktards seem to be intent on maximising their attack service. Which is infinitely stupid in something deeply entwined with the basic functioning of the OS. Such things should be kept small and simple so they can be thoroughly audited and have little to go wrong.
I'd pretty much ignored that anti-systemd rantings so far as being over-reaction. Until this. Damn. I like CentOS. But unless somebody comes out with a systemd-less variant it looks like I'll be switching to devuan when support ends for the version I'm running. Grrrrrrrrrrrrr.
...Linux already has a bunch of DNS resolvers...
But I thought that was what you were supposed to do in Linux: if you don't like something - regardless of whether it works or not - you go out and write your own version so that we find ourselves with endless variations on a theme.
<duck>
Like others here, humbled by my continuing ignorance of the latest nasties that freedesktop.org might have grafted on to the vampire squid that is systemd, I read through the entire article and became concerned. As with Gnome Shell and other pitifully poorly documented software, I assumed _a priori_ that my machines would be at risk. Had the reporter done even some minimal outside research, say even spun up a few Live versions of the major Linux distros, many of us could have been enjoying our morning coffee instead of frantically checking our machines.
CentOS/RHEL 7 (where systemd begins in the RH universe): systemd-resolved does not exist.
Fedora 25+ (may personal workstation): systemd-resolved vendor disabled by default.
There you go, the actual results of actual f*ing research. Advice for the future: Get a copy of VMware Workstation (Parallels if you're a fruit-merchant, or KVM if you're smart enough to run Linux), and have the latest spins ready to fire up for examination, instead of spending all your time in Overwatch.
I mean apparently there's a common missconception that that resolver runs as PID 1. I haven't checked that, but let's see how the fanboys react to this:
As far as I've read the discussion only one pointed out that this is an incorrect assumption.
All the rest just blamed people to not understand systemd, and therefore be idiots without giving any indication at what assumption was wrong.
Please, if you want symphaty for your cause (not an easy task) please at least try to be on a level moral playing field with those who criticise you. Don't call them idiots, respond to their critisism in a logical way. Otherwise you'll end up looking like idiots. If you have arguments that are not easily argued away, use them. If you don't have them, maybe you should reconsider your opinion.
what's fascinating is how the SystemD fanboys react
Just, argh!! - It's also horrifying how the SystemD haters react....nobody seems willing to contradict what seems one of the key points of anti-systemd scripture.
Neither camp comes out well in this forum - and for the record, resolver is running on my Ubuntu 17.04 install I'm currently using, pid 974.
My Arch machine is awaiting parts, so no idea there just now.
Well there's a deeper problem with SystemD in the eyes of the people who don't like it. It basically boils down to values like simplicity, and being able to choose what software they run on. Yes, previous init systems were not very simple either, but at least that was based on shell scripts. If people had learned about actual SysV init, they'd probably want that.
The Pro-SystemD arguments always seem to turn around "being modern", even though most of their ideas have already been implemented in Windows NT.
It seems like an example of that phase most learning programmers go through wanting to re-invent the world in a more complex way. More experienced programmers have learned to live with that feeling.
They can still run their scripts on a systemd box if they really want to, they just have to learn to configure it. systemd was written primarily for the VM and container users where they need to shutdown and reboot rapidly. Having a totally standard way of running a system no matter what distro you use was also a target. What computers are for if not to make repetitive jobs and life easier and consistent.
<Having a totally standard way of running a system no matter what distro you use was also a target.>
What like System V? :)
Systemd by that standard is still bass ackwards, people who need a faster/more deterministic boot sequence should by that logic able to load systemd as an alternative to a default of system v/init/upstart. That way you keep compatibility and reliability unless extra functionality is needed.
They couldn't do that because they let the scope of the project get out of control. It also caused it to take forever to develop, and as a result, was pushed out buggy, and left incomplete. Badly managed projects tend to turn into badly coded projects.
"Are they running a reboot farm?"
No. They are running a Windows server farm. Where stopping/starting individual services with the /etc/init.d scripts is beyond their comprehension.
Yes, systemd makes for faster startups. In a world where every time you change anything you have to restart the O/S.
> I mean apparently there's a common missconception that that resolver runs as PID 1.
I'm no systemd fan but it looks to me like "pid 1 does DNS" is indeed a misconception: https://github.com/systemd/systemd/blob/d60c527009133a1ed3d69c14b8c837c790e78d10/src/resolve/resolved.c
"System D is a Line troop tradition. The men organize themselves into small units and go into a section of town where they all drink until they can't hold any more. Then they tell the saloon owners they can't pay. If any of them causes trouble, they wreck his place, with the others converging onto the troublesome bar while more units delay the guard."
-Jerry Pournelle, West of Honor
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
