4 ms·

Would an OpenBSD-style minimum functionality Unix philosophy designed init system stop a developer from taking over as maintainer of a different upstream projec

Would an OpenBSD-style minimum functionality Unix philosophy designed init system stop a developer from taking over as maintainer of a different upstream project, allowing them to submit malicious patches?

jbverschoor 3y ago
How would you handle dependencies, port, socket, timed triggers etc? 10000s lines of boiler plate code? Very easy to skip something in there. Why do we need to repeat everything? The problem is exactly that.. preprocessing, build scripts etc. Everything is a script and is therefore executable instead of a configuration file/statement which only increases the attack surface
- kemotep 3y ago
  The grandparent comment was about how the issue was actually systemd. My comment is pushing back against that. As you point out, that isn’t a simple swap out. The replacement to systemd can be as complicated and intertwined as systemd is today if not more. But what init system you use is irrelevant to the issue of what do you do when an upstream project is taken over by a malicious developer?
  - denton-scratch 3y ago
    > The grandparent comment was about how the issue was actually systemd. It's not my view that "the issue was actually systemd". The issue was a complex, sophisticated attack by someone taking a long view. But the attacker injected his code into the system by manipulating part of systemd into loading a fairly obscure compression library that he had hacked. Systemd is of course more-or-less omnipresent these days. Why does an init system need to load libraries at all? Well, it doesn't, unless it has arrogated to itself much more functionality than PID1 should ever have.
    - kemotep 3y ago
      The init system was utilized in a supply chain attack. Fixing the init system helps but is only a bandaid to the issue of supply chain attacks.
    - dralley 3y ago
      libsystemd isn't the init system, it's a shared library
- yjftsjthsd-h 3y ago
  > How would you handle dependencies, I don't think most people mind system as a service manager, if that's all it did. > port, socket, That's inetd. > timed triggers That's cron. > etc? Etc.

jbverschoor 3y ago

How would you handle dependencies, port, socket, timed triggers etc? 10000s lines of boiler plate code? Very easy to skip something in there. Why do we need to repeat everything? The problem is exactly that.. preprocessing, build scripts etc. Everything is a script and is therefore executable instead of a configuration file/statement which only increases the attack surface

kemotep 3y ago
The grandparent comment was about how the issue was actually systemd. My comment is pushing back against that. As you point out, that isn’t a simple swap out. The replacement to systemd can be as complicated and intertwined as systemd is today if not more. But what init system you use is irrelevant to the issue of what do you do when an upstream project is taken over by a malicious developer?
- denton-scratch 3y ago
  > The grandparent comment was about how the issue was actually systemd. It's not my view that "the issue was actually systemd". The issue was a complex, sophisticated attack by someone taking a long view. But the attacker injected his code into the system by manipulating part of systemd into loading a fairly obscure compression library that he had hacked. Systemd is of course more-or-less omnipresent these days. Why does an init system need to load libraries at all? Well, it doesn't, unless it has arrogated to itself much more functionality than PID1 should ever have.
  - kemotep 3y ago
    The init system was utilized in a supply chain attack. Fixing the init system helps but is only a bandaid to the issue of supply chain attacks.
  - dralley 3y ago
    libsystemd isn't the init system, it's a shared library
yjftsjthsd-h 3y ago
> How would you handle dependencies, I don't think most people mind system as a service manager, if that's all it did. > port, socket, That's inetd. > timed triggers That's cron. > etc? Etc.