> The developer talks about the weaknesses of sudo, and how it has a large possible attack surface
Poettering's hypocrisy is painful.
replies(2):
Poettering's hypocrisy is painful.
Because that's what he's complaining about
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."
And neither Poettering nor the systemd developers patched said, the Debian people did that. Seems weird to blame systemd for that?
The inclusion of a library to send notifications shouldn't have external dependencies, it shouldn't need them. The library is included in the customer's codebase at execution time, so it is a hole in the customer's security model. This immediately opens a supply chain attack vector (which is what we saw).
This is being taken as evidence that they shouldn't have responsibility for truly security sensitive code - the replacement of sudo.
Some of this is a long-term dislike for systemd and some representative bias. However, Systemd has missed the opportunity to make their client libraries safer.
Personally? I wouldn't have thought to limit the dependencies of my client libraries. It's a growth and project age thing. One moment you're on one side of a line, the next you have to skill up and do things differently.
Using systemd as intended shouldn't result in security holes for their customers.
And again, Poettering's complaint with sudo is specifically about it being a SUID binary, so this discussion isn't even related to the thing you're accusing them to be hypocritical about... SUID is more than just "code running as root", it's "code running as root in an attacker-controlled environment". That last part is the important one.
This attack demonstrates that they should be tightly focused and have minimal downstream dependencies.
I don't have any experience with systemd, but typically, people will bundle _all_ of their client libraries into one .so and say "use that".
However, what needs to happen is there should be multiple .so's, one for each sub-API. At least there should be libraries for frequently used shim code (like notifications seems to be).
Then systems that need to push information don't need to pull in the dependencies for other parts of the overall systemd interface.
I can't think of a reason why pushing local notifications would require a compression library. The notifications should be information heavy already, so not very compressible.
As I said, it's a growth and project age thing. One moment you're on one side of a line, the next you have to skill up and do things differently.
How the team responds is what is important. That is why people are objecting to the SUID work. Not because sudo isn't a hole, but that the systemd team isn't considered responsive enough to take it on.
I know I'm taking lessons from this to my work. It's an unpleasant mirror for me to look in.