But libsystemd is not linked to xz only. By removing it, sshd is free of many other potential risks.
Still the question remains: what technology could be implemented to mitigate this type of attack (beyond sshd)?
For example, Linux sandboxing is poor, and SeLinux is not usually enforced.
Why should sshd be allowed to call an xz function directly without xz being an immediate dependency.
I'm not sure what all that would entail with the ifunc stuff, but I remember encountering a glibc linking change moving from Red Hat 6 to RH7 that did something similar and broke the build process for some legacy code.
UNIX ? (do one thing and do it well).
When your program links with 20 libraries, i have i very hard time to believe that security is one of your goals.
There was a pull request to stop linking liblzma into libsystemd a month before the backdoor was found
https://github.com/systemd/systemd/pull/31550
This was likely one of many things that pushed the attackers to work faster, and forced them into making mistakes.
They felt threatened by the idea that open source maintenance can ever go wrong and started attacking me. They argued closed source was worse.
That was not my point at all. I was not raising a weakness of open source. I was just pointing out that linking to libsystemd had that kind of problem.
