Run0, a systemd based alternative to sudo, announced

> The developer talks about the weaknesses of sudo, and how it has a large possible attack surface

Poettering's hypocrisy is painful.

Is it? Does systemd's sudo replacement also have a lot of complex code running as root in a suid binary?

Because that's what he's complaining about

People blame systemd for making the liblzma problem larger than it should have been.

https://marc.info/?l=openbsd-misc&m=171227941117852&w=2

"Liblzma ends up dynamically linked to sshd because of a systemd-related extension added by many Linux packagers that pulls in liblzma as an unrelated dependency."

https://news.ycombinator.com/item?id=39866076

"openssh does not directly use liblzma. However debian and several other distributions patch openssh to support systemd notification, and libsystemd does depend on lzma."

So that's your best shot against systemd?

- Linux packagers decide to patch sshd to use libsystemd for a notification, that could have been trivially done without this library.

- libsystemd depends on libzlma

- libzlma depends on xz

And therefore, systemd is insecure?

And what does this have to do with the fact that SUID is a terrible idea that needs to go?

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.