151–160 of 162 posts
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...
I wonder what security problems Linux kernel had in that time? Other init systems (probably) had no exploits because dull rock can be exploited only so much.
Earlier quoted context omitted.
What's the advantage of such an architecture?
The advantage is that the kernel panics if PID 1 ever crashes, so I want PID 1 never to crash or even be able to crash. It also means I want the binary to have as little of an attack surface as possible, and particularly I don't want it listening to dbus or having links to a QR generation library. This is a solved problem with multiple good solutions [1] [2] [3], so I can easily avoid those issues by not using system…
By the way, systemd doesn't listen to dbus (it uses the dbus protocol for IPC) and does not link to a QR generation library (journalctl does, which is your usual unprivileged program).
Earlier quoted context omitted.
Sure, security has performance costs, but I don't think an init system (whose job, ultimately, is to fork and exec a lot of things) is going to be harmed by it. And, anyways, if you had a libcoreutils, suddenly you're stuck worrying about symbol versions, LD_PRELOAD, etc., etc., whereas simply executing the binary is pretty simple.
> I don't think an init system (whose job, ultimately, is to fork and exec a lot of things) is going to be harmed by it. The performance overhead of the script-heavy init system that preceded it is in fact one of the core design points of systemd. Boot time still matters in some environments, and the old init scripts were completely out of hand.
No this really isn't a primary design goal in systemd at all. In fact, Lennart Poettering even lists that misconception as myth number two on http://0pointer.de/blog/projects/the-biggest-myths.html
Earlier quoted context omitted.
I wonder what security problems Linux kernel had in that time? Other init systems (probably) had no exploits because dull rock can be exploited only so much.
Well, if dull rock can't be exploited, maybe we should be putting dull rock in PID1?
Earlier quoted context omitted.
van Smoorenburg init dates from 1992. Considering its bug history from age 12 to age 25 and comparing that to systemd's bug history from age 5 to age 6 is at the very best misleading. 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 codi…
Why is it misleading? Why if we had something safe and stable because of its age and refinement is that an excuse to stuff something less mature in its place? 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…
Earlier quoted context omitted.
Well, if dull rock can't be exploited, maybe we should be putting dull rock in PID1?
This exploit isn't in PID 1 and neither are all of the other things people claim are in PID1. PID1 in systemd doesn't contain much more than it needs to, it handles parsing unit files which could arguably be split out but that still leaves something highly privileged to parse them, but just about everything else would be a major pain to separate from PID 1 as most of it is how to walk the dependency graph from where…
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.
Earlier quoted context omitted.
The "sysvinit" binary package has had a total of 2 bug reports tagged "security" filed in Debian's bug tracker. That's over the entire history of the package that goes back to at least 2004. 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 quer…
van Smoorenburg init dates from 1992. Considering its bug history from age 12 to age 25 and comparing that to systemd's bug history from age 5 to age 6 is at the very best misleading. 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 codi…
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.
Earlier quoted context omitted.
The "sysvinit" binary package has had a total of 2 bug reports tagged "security" filed in Debian's bug tracker. That's over the entire history of the package that goes back to at least 2004. 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 quer…
At the same time, the list of bug reports that the init scripts used with sysvinit had (because they all had to replicate the same code, in different ways, patched together from some stackoverflow post) is uncountable.
Systemd's problems are deeper in. One major one is most of its design, and its entire conception.
Earlier quoted context omitted.
van Smoorenburg init dates from 1992. Considering its bug history from age 12 to age 25 and comparing that to systemd's bug history from age 5 to age 6 is at the very best misleading. 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 codi…
so if Vsinit is stable and bug free right now , why switch to something that isn't? 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 wha…
It is also erroneous to propound the old There Is Only System 5 init And systemd fallacy, which is just bunkum.