3 ms·
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
by tgv 3y ago
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.
- deng 3y ago> 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.
- tgv 3y agoDecoupling/single-reponsibility is sort of lesson #1 in software engineering. > then come up with a better one. Really?
- deng 3y ago> 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?
- jononor 3y agoPackage 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.
- mike_hearn 3y agoIf 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.
- tgv 3y agoThe 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.
- throwaway7356 3y ago> 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?
- mike_hearn 3y agoNobody was silently assuming the systemd maintainers were reviewing the source tarballs of every dependency for obfuscated back doors.
- 3y ago