First, getting rid of setuid (I guess you'd have to get rid of the whole thing, not just the permission bit) is not the same as making systemd an integral part of the OS.
Second, when even the package maintainers can make such "trivial" mistakes, something is wrong. You'd expect a component such as systemd to be much more trustworthy than some random library.
I'm not arguing against systemd, just that it seems to grow and grow, and is not the correct place for security. It security is obviously broken.
If it was "obviously" broken why was the xz backdoor such a shock to everyone? Do you personally audit the library dependencies of every tool you run, including core servers that come with your distribution? I think people don't do this.
Also, even before the backdoor was discovered, the systemd team were making libxz be dynamically loaded only in the cases where it was needed which would have killed the backdoor dead. There's some evidence that this might have actually caused the backdoor to be sped up and hence led to its discovery. Claims that systemd has bad security have to explain why it was already implementing practices that would have blocked the xz backdoor without it even being discovered. That seems pretty decent to me.
The point is that (even) the systemd maintainers do not vet their dependencies. As an attack vector, it is the (second?) highest level, yet they did not assume the responsibility. Everybody silently assumed they did, hence the shock.
> Claims that systemd has bad security have to explain why it was already implementing practices ...
No, they don't. It doesn't take away the fact that they did not check xz, and probably only few of their other dependencies.
That would be irresponsible and strengthen the case against run0 as a replacement. And let's be honest this time: the argumentation is that it's there to replace sudo.
> It doesn't take away the fact that they did not check xz, and probably only few of their other dependencies.
Xz is also used by Debian's package manager (both dpkg and apt). Or tar. Or the Linux kernel. Or... It already was a system library on Linux systems before systemd started using it as well.
Your post reads like you have no real idea what Xz is and how it is used.
Btw, do you think the Linux kernel developers are also clueless for using Xz?
Package maintainers of a distro can do absolutely anything to a package. With zero input from upstream developers. Some distros have more tradition for patching software than others. An upstream like systemd (or openssh) can hardly be blamed for what others do with their software.
> First, getting rid of setuid (I guess you'd have to get rid of the whole thing, not just the permission bit) is not the same as making systemd an integral part of the OS.
It absolutely is. sudo allows you to execute code as another user. If you want to do that without giving sudo itself administrative privileges, this has to be done through the service manager, which creates a completely new, elevated process and handles communication with that. This is how it should be done (and BTW, this is pretty much how also the new sudo for Windows works). Now Lennart for some reason prefers systemd as this service manager - you might disagree with that choice, but then come up with a better one.
> Decoupling/single-reponsibility is sort of lesson #1 in software engineering.
Well said. What makes you think systemd does not do this? Have you ever even looked at systemd in any amount of detail? Do you think it is one big binary running as PID1 doing everything?
Second, when even the package maintainers can make such "trivial" mistakes, something is wrong. You'd expect a component such as systemd to be much more trustworthy than some random library.
I'm not arguing against systemd, just that it seems to grow and grow, and is not the correct place for security. It security is obviously broken.