Live data from Hacker News

Ubuntu 24.04 (and Debian) removed libsystemd from SSH server dependencies

fosstodon.org

11–20 of 62 posts

Re: Ubuntu 24.04 (and Debian) removed libsystemd from SSH server dependencies

#11
post #6

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.

See: Qubes OS.

Re: Ubuntu 24.04 (and Debian) removed libsystemd from SSH server dependencies

#12

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.

I pointed out this weakness the other day on the internet. I got attacked by open source software armies.

Thanks for sharing.

Re: Ubuntu 24.04 (and Debian) removed libsystemd from SSH server dependencies

#13
post #3
post #2

As 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?

> 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

#14

libsystem 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?

I like parts of systemd very much: units and their sandboxing/isolation/chroot of processes.

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

#15
post #3

Earlier 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.

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

#16
post #15

Earlier 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.

Try that supply chain attack on dropbear running as ssh server on devuan. Simple utility on a simple system made of simple utilities

Re: Ubuntu 24.04 (and Debian) removed libsystemd from SSH server dependencies

#17
post #7

I 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.

Re: Ubuntu 24.04 (and Debian) removed libsystemd from SSH server dependencies

#18
post #7

I 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.

> 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

#19
post #18

Earlier 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.)

OK - try an LUbuntu Install disk for 22.04; run the installer, after Welcome,Location,Keyboard in the Partition task, create a new Partition Table; make a new disk partition, see the list of available partition types, choose ext4; see FLAGS [apple-tv-recovery,bios-grub,boot,diag,hidden,hpservice,lba,legacy-boot,lvm,msft-data,msft-reserved,palo,prep,raid,root,swap]

Re: Ubuntu 24.04 (and Debian) removed libsystemd from SSH server dependencies

#20

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.

I pointed out this weakness the other day on the internet. I got attacked by open source software armies.

FOSS zealots are not always security experts.
Post reply on HN