Hacker News Reader

Comment by KuiN | Hacker News Reader

Found 51 CVEs relating to systemd since 2012 in a naive search[0]. All software of systemd's complexity has bugs, but a CVE every ~2 months over 7 years isn't hugely encouraging. Never mind the ever increasing surface area as systemd seems to take on ever increasing amounts responsibility in an average Linux system. I'm absolutely biased and have been unconvinced from day 1, but I've not seen much to dull my scepticism either.

[0] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=systemd

View on HN

While systemd is a significant downgrade in security compared to init systems written in shell, which is memory safe, this particular hole can be attributed to many things, but systemd is barely one of them. Linux networking stack is pretty messy, iptables can barely be called a firewall with awful usability and there is no best practice to use firewall to limit the surface you expose to other things on the network. It doesn't have to be like that. I remember when I used freebsd the first time there was already a suggestion somewhere to block packets with local ip addresses coming into wan interfaces and block, allow packets based on "icmptypes" and "established" flags, and ipfw itself was nice and usable, so it was always a big part of regular practice on freebsd.

> iptables can barely be called a firewall

Why?

I'm not trying to troll here but if I replace 'systemd' with 'linux' there are over 5k.

The truth about computer security is that it is abismal. Somethings are better than others but complex software written in unsafe languages...unsafe is gonna unsafe.

If you want to find reasons to dislike systemd, you’ll find plenty to pick and choose from. But if you instead want to have systemd, and therefore want to find reasons that it’s worth it, you’ll likewise find lots of those. Whatever your initial opinion, you’ll find plenty of things to support your case.

Meta-reasons for wanting to like systemd in the first place include:

1a. It has plenty of nifty new features using the latest Linux features, most prominently cgroups.

2a. It makes it relatively easy to take advantage of those features for your own services, and/or to alter existing services to your liking.

3a. Probably for reasons 1a and 2a, most Linux distributions have long since changed to use systemd, and getting used to using a standard system is useful in real life.

The only meta-reasons for not liking systemd which I have seen are:

1b. It doesn’t work the way Unix always worked, and some people don’t like using it, since they don’t know all the ins and outs like they might do with the old systems.

2b. It seems to acquire, subsume and supplant lots of previously separate Unix systems like init, cron, syslog, ifconfig, etc. This, combined with 1b, only exacerbates the pain.

All other criticisms that I have seen can be adequately explained as being after-the-fact rationalizations stemming from 1b and 2b.

(Note: Anyone still using ifconfig on Linux should get with the program and start using ip(8) already: https://manpages.debian.org/testing/iproute2/ip.8.en.html)

Longevity and stability is a big issue for me. Systemd may be the new way to do things, but will it be doing it the same way in 5 years? I'm not confident it will.

iproute has nothing to do with systemd, and I use it a lot (although I prefer the default visibility of "ifconfig" rather than "ip -o a" to see what IPs I have on what interfaces).

Systemd does have a wiki page about this:

https://www.freedesktop.org/wiki/Software/systemd/InterfaceS...

You're neglecting one other major reason for disliking systemd:

3b. Not working as advertised.

I have consistently run into major issues on various machines with trivial configurations. I am left with no choice but to ban systemd from all my machines because it's not usable.

I hear you. When I first tried to use systemd-networkd, it didn’t work. Last I tried, I couldn’t get systemd-resolved to work they way I like to configure things. However, systemd itself has mostly worked for me, and I trust (since its use is so common and upstream seems active) it’s only going to get better, and all these problems will be fixed. It’s all in what you personally want to believe in.

You are perfectly justified in avoiding what you see to be problematic software. However, it is mainstream, and bugs seem to be fixed over time. If we assume this to be true, there will come a time when systemd is working perfectly adequately for your needs, but you are completely unprepared to use it, since you haven’t had the training which most everyone else has gotten until then. You see? I have my rationalizations and you have yours.

I think this kind exposure is inevitable with something as big as systemd. If you look at the old scripts-and-daemons hairball that systemd replaces, it has a lot of security warts too. (Albeit with 20 years of wart removal as well.)

What worries me is that systemd is not engineered and managed as a project with this kind of risk. Instead it feels like a lot of cowboy coding.

SystemD should not be as big as it is.

> If you look at the old scripts-and-daemons hairball that systemd replaces, it has a lot of security warts too.

Not even close. Scripts were always memory safe and limitations of shell didn't allow to go crazy with things and introduce security issues left and right.

Whether shell is memory-safe is completely irrelevant as the language has more significant safety issues with regards to quoting, eval and such.

And second reason why it is irrelevant is that the traditional bunch-of-shell-scripts init system does not process any kind of untrusted input.

It does deal with some untrusted input, often not directly in shell though, but through other tools.

Instead you had quoting bugs where the shell scripts ended up rm -rf /'ing your machine.

I've seen this argument raised a couple of times so far on the internet, and when I offer the same search with the keyword "linux" people seem to feel like it's not exactly an apples to apples comparison.

So, maybe you can try the search with the name of your favourite project (that maybe is similar in scope and user base to systemd) and tell us what you find? Are the numbers that dissimilar?

how many were memory safety as a root cause?

Reply on news.ycombinator.com