Wow. That's, let's see... Two exploits over the course of about a year?
Hey, I wonder what security problems OpenRC, sysvinit, and bsdinit have had in that time?
Food for thought...
Hey, I wonder what security problems OpenRC, sysvinit, and bsdinit have had in that time?
Food for thought...
If I extend the search to all packages built from the "sysvinit" source (which includes packages like initscripts and sysvinit-utils), the count increases to 8.
(source: https://www.debian.org/Bugs. I'm not linking to exact queries since they take quite some time and HN has a tendency of taking down Debian's bug tracker)
At age 4, van Smoorenburg init was panicking when /etc/inittab had blank lines. At age 6, van Smoorenburg init was having a buffer overflow in init.c fixed.
Counting the CVE bugs is a silly approach. It is far better to look at the coding practices that are followed in a project. Are APIs designed and implemented consistently? When a functional change is made, is the doco always changed at the same time to match? Are the reasons for seemingly odd things properly recorded for maintenance programmers in the future to read? There are many, far better, questions to ask in place of how many CVE listings something has had in some arbitrary interval in its lifetime.
Personally I like unit files rather than bespoke Bash scripts, I like dependency-driven parallel startup, and I like getting a daemon watchdog for free. That's about where I'd have ended the feature requests, though. I'd also like it to be roughly as secure as what it's replacing.
Then read on a find a whole lot of better questions to ask. For bonus points, try asking yourself them about various systems. (-:
Also, systemd has had two bad exoploits over the course of about a year. The flaws in Vsinit you point out were two years apart, and the former of the two could only be triggered by someone who was already an admin, and gave no opportunity for privesc.
Given, init panicking is never acceptable, but it's a heck of a lot better than what systemd did.
It is also erroneous to propound the old There Is Only System 5 init And systemd fallacy, which is just bunkum.
>Anyone who erroneously thinks that van Smoorenburg rc is bug free hasn't spent time fixing the whole host of faulty, incomplete, and rickety van Smoorenburg rc scripts that exist.
I never said it was bug-free, I said that the problems with the rc scripts aren't inherent to the sysvinit model.
Systemd's problems are deeper in. One major one is most of its design, and its entire conception.
Other init systems (probably) had no exploits because dull rock can be exploited only so much.
From what I understood from the systemd code is that it's written pretty defensively. I quite like systemd because its useful, thought out, etc. But then I want all that without any drawbacks (because why not!). Probably unrealistic, but nice to strive for a perfect project.
In addition, I don't see all that many other daemons running that can be attributed to systemd: where did crond go? What daemon replaced it? Because from out here, it seems that it was sucked into the core, and don't tell me that's an essential.
Finally, even if the core is rock solid, there's no excuse for these kinds of exploits in core software, which systemd seems to want to be, especially not this frequently.