Earlier quoted context omitted.
> A back door in the same library is not likely. But libsystemd is not linked to xz only. By removing it, sshd is free of many other potential risks.
Correct, I misread. 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.
Ubuntu 24.04 (and Debian) removed libsystemd from SSH server dependencies
11–20 of 62 posts
Re: Ubuntu 24.04 (and Debian) removed libsystemd from SSH server dependencies
#12Earlier quoted context omitted.
> A back door in the same library is not likely. But libsystemd is not linked to xz only. By removing it, sshd is free of many other potential risks.
I pointed out this weakness the other day on the internet. I got attacked by open source software armies.
Re: Ubuntu 24.04 (and Debian) removed libsystemd from SSH server dependencies
#13As per the well known XZ-utils backdoor, we decided to take a step further and drop libsystemd dependency altogether by implementing the missing bits with few small patches (one upstream, the other to be forwarded).
A back door in the same library is not likely. It drew attention and many looked into it. What could be done to prevent supply chain attacks more broadly?
The UNIX philosophy was right all along - each tool does one simple thing.
Re: Ubuntu 24.04 (and Debian) removed libsystemd from SSH server dependencies
#14libsystem is such a bizarre abstraction covering far too much surface area. The name alone is a code smell. Why is the same library used for both internal service management and for services implementing on-demand launches and notifications?
Many other parts are terrible beyond measure: journald for example.
I think the concept of on-demand processes managed by the end manager is a good idea, but systemd is strong arming the services into accepting its philosophy.
Re: Ubuntu 24.04 (and Debian) removed libsystemd from SSH server dependencies
#15Earlier quoted context omitted.
A back door in the same library is not likely. It drew attention and many looked into it. What could be done to prevent supply chain attacks more broadly?
> What could be done to prevent supply chain attacks more broadly? The UNIX philosophy was right all along - each tool does one simple thing.
Most things we want to do are necessarily complex, so dogmatically adhering to "one simple thing" necessarily drives you towards a towering heap of composed dependencies.
If you want to get rid of the supply chain, you want everything specifically to be non-composable, so that everything has to be reinvented from scratch for that specific solution.
Re: Ubuntu 24.04 (and Debian) removed libsystemd from SSH server dependencies
#16Earlier quoted context omitted.
> What could be done to prevent supply chain attacks more broadly? The UNIX philosophy was right all along - each tool does one simple thing.
I can't tell if this is sarcasm or not. Most things we want to do are necessarily complex, so dogmatically adhering to "one simple thing" necessarily drives you towards a towering heap of composed dependencies. If you want to get rid of the supply chain, you want everything specifically to be non-composable, so that everything has to be reinvented from scratch for that specific solution.
Re: Ubuntu 24.04 (and Debian) removed libsystemd from SSH server dependencies
#17I thought Ubuntu is a downstream of Debian, did I take it wrong?
Re: Ubuntu 24.04 (and Debian) removed libsystemd from SSH server dependencies
#18I thought Ubuntu is a downstream of Debian, did I take it wrong?
the relationship shifts, many parts are unclear.. especially after MSFT took direct interest in Ubuntu, with adding custom partition types ( edit msft-reserved, msft-data) to the OS installer, and new code to require signed encryption keys to the UEFI boot; keys registered or directly issued by MSFT.
The only evidence I can find of this... Is another comment from you. (Googled: '"MSFT_PRIVATE" partition'. One result.)
Re: Ubuntu 24.04 (and Debian) removed libsystemd from SSH server dependencies
#19Earlier quoted context omitted.
the relationship shifts, many parts are unclear.. especially after MSFT took direct interest in Ubuntu, with adding custom partition types ( edit msft-reserved, msft-data) to the OS installer, and new code to require signed encryption keys to the UEFI boot; keys registered or directly issued by MSFT.
> MSFT_PRIVATE The only evidence I can find of this... Is another comment from you. (Googled: '"MSFT_PRIVATE" partition'. One result.)
Re: Ubuntu 24.04 (and Debian) removed libsystemd from SSH server dependencies
#20Earlier quoted context omitted.
> A back door in the same library is not likely. But libsystemd is not linked to xz only. By removing it, sshd is free of many other potential risks.
I pointed out this weakness the other day on the internet. I got attacked by open source software armies.