9 ms·

Sure, but the main alternative is systemd which is architected in a way that just isn't secure, and opens it up to a whole bunch of new and exciting CVEs. Ther

Sure, but the main alternative is systemd which is architected in a way that just isn't secure, and opens it up to a whole bunch of new and exciting CVEs. There's just way too much going on in PID1, written in a memory unsafe language. I don't see a technical reason why it couldn't have a minimal PID1, and a few setuid programs. Aside from it making it possible to run systemd inside a docker container, which I presume redhat/IBM is strongly against, preferring you to use their in-house containerization tools like systemd-nspawn. It's just never going to be viable from a security point of view with how it's architected.

blueflow 2y ago
> I don't see a technical reason why it couldn't have a minimal PID1, and a few setuid programs. More detailed: Systemd conflates the init system (PID1) and service supervisor. And as a service supervisor, it isn't really that reliable.
Arch-TK 2y ago
There are literally at least 3 well designed and featureful alternatives to OpenRC which are not systemd: daemontools, runit, and s6-rc. There are also other lesser known options. For a real world in-situ use of runit, see voidlinux. It could be handled better but at this present moment it is at least no more clunky than using OpenRC.
pelasaco 2y ago
> Sure, but the main alternative is systemd which is architected in a way that just isn't secure, and opens it up to a whole bunch of new and exciting CVEs. This is a general "back in the days always was better" answer. Fact is that along the years systemd had less than 50 CVEs published, it reinvented for good the whole initialization process and linux administration in general, and together with SELinux are great foundation for any modern Linux distribution. Sure RC was super simple, but systemd is just the evolution that Linux needed to become what it is today.
- traverseda 2y ago
  https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/3608324/us-and-international-partners-issue-recommendations-to-secure-software-products/ https://www.nsa.gov/Press-Room/Press-Releases-Statements/Pre... When there's a CVE in a program written in a memory-unsafe language that has a position of privilege in your security model, that's a much much bigger deal than if there's a poorly written bash script running as a user. Seperate out your service manager from your pid1, pid1 needs to just be responsible for reaping orphan processes. If you're going to have a monolithic daemon in that privileged position at least write it in a memory-safe language, as that's where most of the nasty RCE vulns come from.
- b112 2y ago
  Sure RC was super simple, but systemd is just the evolution that Linux needed to become what it is today. At this, I just vomited a little in my mouth. Linux owes nothing to systemd. In every measurable way, systemd adds more complexity, reduces security by expanding the vulnerability footprint, creates a monolithic ecosystem, and handles everything far worse than, for example, Debian's use of sysvinit. I spend more time dealing with systemd edge cases, and bugs, and security issues every few months, than I did in 30 years of other init systems. Systemd is a step backwards.
  - TacticalCoder 2y ago
    > Systemd is a step backwards. It totally is. I see the appeal: it's, on the surface, easy. But this comes at a cost. Turning Linux into Windows by replicating svchost.exe shouldn't be applauded by the Linux community. I'm glad the BSDs are still out there and I'm glad there are still non-systemd Linux distros out there and I'm even more glad some systemd distros haven't completely shut the door on moving back away from systemd. Do I write a systemd service once in a while? Yup, I do. Is it easy? Kinda, at first. But we shouldn't be too excited about superficial simplicity. Something has been lost in exchange. The monster systemd squid spreads its infinite tentacles on everything it touches while being PID 1, making sure that a countless number of current and future exploits (or backdoors) are possible. We've got Linux's PID 1 (for most distros) controlled by a MS employee, who replicated Windows' svchost.exe. And people are all excited? I personally cannot wait for another, better, init system to come out and replace systemd. Meanwhile I'm glad there's choice: OpenBSD, Alpine Linux, Devuan, etc.

blueflow 2y ago

> I don't see a technical reason why it couldn't have a minimal PID1, and a few setuid programs. More detailed: Systemd conflates the init system (PID1) and service supervisor. And as a service supervisor, it isn't really that reliable.

Arch-TK 2y ago

There are literally at least 3 well designed and featureful alternatives to OpenRC which are not systemd: daemontools, runit, and s6-rc. There are also other lesser known options. For a real world in-situ use of runit, see voidlinux. It could be handled better but at this present moment it is at least no more clunky than using OpenRC.

pelasaco 2y ago

> Sure, but the main alternative is systemd which is architected in a way that just isn't secure, and opens it up to a whole bunch of new and exciting CVEs. This is a general "back in the days always was better" answer. Fact is that along the years systemd had less than 50 CVEs published, it reinvented for good the whole initialization process and linux administration in general, and together with SELinux are great foundation for any modern Linux distribution. Sure RC was super simple, but systemd is just the evolution that Linux needed to become what it is today.

traverseda 2y ago
https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/3608324/us-and-international-partners-issue-recommendations-to-secure-software-products/ https://www.nsa.gov/Press-Room/Press-Releases-Statements/Pre... When there's a CVE in a program written in a memory-unsafe language that has a position of privilege in your security model, that's a much much bigger deal than if there's a poorly written bash script running as a user. Seperate out your service manager from your pid1, pid1 needs to just be responsible for reaping orphan processes. If you're going to have a monolithic daemon in that privileged position at least write it in a memory-safe language, as that's where most of the nasty RCE vulns come from.
b112 2y ago
Sure RC was super simple, but systemd is just the evolution that Linux needed to become what it is today. At this, I just vomited a little in my mouth. Linux owes nothing to systemd. In every measurable way, systemd adds more complexity, reduces security by expanding the vulnerability footprint, creates a monolithic ecosystem, and handles everything far worse than, for example, Debian's use of sysvinit. I spend more time dealing with systemd edge cases, and bugs, and security issues every few months, than I did in 30 years of other init systems. Systemd is a step backwards.
- TacticalCoder 2y ago
  > Systemd is a step backwards. It totally is. I see the appeal: it's, on the surface, easy. But this comes at a cost. Turning Linux into Windows by replicating svchost.exe shouldn't be applauded by the Linux community. I'm glad the BSDs are still out there and I'm glad there are still non-systemd Linux distros out there and I'm even more glad some systemd distros haven't completely shut the door on moving back away from systemd. Do I write a systemd service once in a while? Yup, I do. Is it easy? Kinda, at first. But we shouldn't be too excited about superficial simplicity. Something has been lost in exchange. The monster systemd squid spreads its infinite tentacles on everything it touches while being PID 1, making sure that a countless number of current and future exploits (or backdoors) are possible. We've got Linux's PID 1 (for most distros) controlled by a MS employee, who replicated Windows' svchost.exe. And people are all excited? I personally cannot wait for another, better, init system to come out and replace systemd. Meanwhile I'm glad there's choice: OpenBSD, Alpine Linux, Devuan, etc.