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?

> - libsystemd depends on libzlma

> - libzlma depends on xz

> And therefore, systemd is insecure?

Yes. You have literally just described the way it is insecure. It bundles a large amount of functionality under a single system, and therefore anything using that functionality is at risk. You seem to be suggesting that Systemd would be secure if you didn't use it, which is obviously fallacious. Anything is secure if you don't use it. Systemd offers this functionality, and did it in an insecure way. You cannot blame users for that. Saying that people shouldn't be using a certain part of Systemd is really the same as saying that part shouldn't exist to begin with. The conclusion is obviously that Systemd should be smaller to decrease the chances of things like this happening.

LZMA is a widely used compression protocol. The kernel uses it. xz - the compression tool that was affected gets used by the kernel build makefiles - they reference it in the build docs https://docs.kernel.org/staging/xz.html. It's absolutely fair from systemd to have this dependency and to use the trusted library that the most fundamental part of the underlying OS uses.

It was purely the attackers choice to leverage the exploit via systemd instead of injecting code in the kernel at build time.

Your speculation on what is right and what was fair is of no consequence to me. Their error was not simply using a compression library, it was creating a large central point of failure. If Systemd was smaller, it would not have caused this error. By being large, it made itself vulnerable. It made itself a target. It made other software insecure. These facts are inescapable. And you cannot justify this by simply saying they didn't do anything wrong right before the attack, or that packagers are to blame, or that other software might also be vulnerable, or anything else that doesn't address the core of the issue: Systemd created the circumstances needed for this to happen. They were warned of he risks they created, and chose to do so anyway. Now those risks have been made manifest – the inevitable result of a fundamentally flawed design.

Why is this an argument specifically against systemd, rather than all large software projects?

Linux kernel, gcc, glibc - all bundle "a large amount of functionality under a single system" - does this make their design fundamentally flawed as well?

I think a micro-kernel architecture would be better in many ways, security being just one of them. With GCC, it couldn't really be separated into logically distinct modules any more than it already is. All of the constituent parts essentially use the full functionality of the base compiler part, so there is little to be gained separating them. It's not as if the C compiler from GCC, could for instance, be written in such a way that it doesn't depend on GCC. GLibc is a large implementation, but the library itself doesn't necessarily need to be large. There are some very small libcs out there.

On the whole, I do not like monolithic software projects, but I can accept that they are necessary or beneficial in some cases. Systemd is simply a much bigger target than these other things because it is an especially bad example. It has many components which are only tentatively connected. It is also more fixable. Alternate init systems are used much more widely than something like Hurd to replace Linux. The laptop I'm typing this from runs GuixSD which ships without Systemd and I can hardly notice the difference. I doubt a different kernel architecture would provide such a seamless experience.

Given how common LZMA as a compression algorithm is, are you certain that your init system of choice doesn’t use it in any way? It’s a very common algorithm in network protocols, it’s a direct dependency of libxml, … - and if any part of your init system uses LZMA, then it just happens not to be affected because the attacker chose to target one specific system.

I wouldn't be affected regardless, because SSH doesn't depend on my init system.

The attacker had essentially full control over a very fundamental library in the Linux ecosystem. They could have leveraged that in a hundred ways.

The attacker chose to target a very specific component of a very specific system. It was their choice, not some sort of technical requirement that made it impossible to use a different attack vector. Just as they chose not to target other Linux distributions that use systemd.

You’re essentially saying “I was safe because the attacker chose to ignore me.” That worked well this time, but it’s a pretty dangerous stance.

When a hacker chooses to attack something, that isn't random. They had to look at a lot of different pieces of software, and decide which would be the best to attack. The choice in this case was Systemd. In other words, if you are looking to do malicious things, Systemd is helpful.

Now I want you to imagine that every piece of software has a score, which tells you how useful it is to hackers. Systemd has a high score, and hence it was chosen for this attack. Your argument is that: there are other pieces of software with a high score so it's fine for Systemd to also have one, since without it there would be other things to attack. My argument is that we should reduce the amount of software that has a high score. Do you think my reasoning or your reasoning will lead to a more secure ecosystem?

The size of libsystemd is immaterial in the case of xz. The attackers had control of xz, and wanted to load it from sshd.

There's lots of projects that link xz, big and small. Patching sshd to include any of them would have implemented the backdoor.

> But other software is also hypothetically insecure.

And I'm sure it'll be the same excuse next time.

> But other software is also hypothetically insecure.

This is not my point.