openssh-portable
openssh-portable copied to clipboard
openssh
systemd: unit files, `sd_notify` support; OpenRC init scripts
Add OpenRC and systemd init files for cross-distribution compatibility. Also includes a rebased and updated sd_notify support patch from #251, in line with usage by Red Hat/Fedora, OpenSuSE, and Debian. Feedback welcome.
The unit files and patch are in use by multiple major distributions. Is there anything blocking this being merged?
In light of recent developments (https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27), it appears that it would be a better idea to inline sd_notify instead and not link to systemd at all. (of course, this isn't my idea)
The unit files and patch are in use by multiple major distributions. Is there anything blocking this being merged?
Willingness from the maintainers here, I guess?
Willingness from the maintainers here, I guess?
License incompatibility and library bloatedness were the reasons. Given recent events we're never going to take a dependency on libsystemd, though we might implement the notification protocol ourselves if it isn't too much work.
In light of recent developments (https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27), it appears that it would be a better idea to inline
sd_notifyinstead and not link to systemd at all. (of course, this isn't my idea)
To quoth poettering (https://news.ycombinator.com/item?id=39867126)
Uh. systemd documents the protocol at various places and the protocol is trivial: a single text datagram sent to am AF_UNIX socket whose path you get via the NOTIFY_SOCKET. That's trivial to implement for any one with some basic unix programming knowledge. And i tell pretty much anyone who wants to listen that they should just implement the proto on their own if thats rhe only reason for a libsystemd dep otherwise. In particular non-C environments really should do their own native impl and not botjer wrapping libsystemd just for this. But let me stress two other things:
Libselinux pulls in liblzma too and gets linked into tons more programs than libsystemd. And will end up in sshd too (at the very least via libpam/pam_selinux). And most of the really big distros tend do support selinux at least to some level. Hence systemd or not, sshd remains vulnerable by this specific attack.
For this:
Given recent events we're never going to take a dependency on libsystemd, though we might implement the notification protocol ourselves if it isn't too much work.
The above makes it seem straightforward and that is probably the correct approach here.
It is courteous to respond to a PR so that it can be improved or dropped. If I was to drop the sd_notify patch would you merge the service definitions?
License incompatibility and library bloatedness were the reasons. Given recent events we're never going to take a dependency on libsystemd, though we might implement the notification protocol ourselves if it isn't too much work.
It's a big pity you didn't say that a year ago. If you had, the PR could have been reworked to implement the notification protocol internally, and then systems today would not have been vulnerable.
Disappointing that lack of interest in collaboration had this unfortunate downside.
then systems today would not have been vulnerable
IMHO the backdoor author(s) would have just targeted some other process/binary or targeted SSHD anyway via other mechanism as Poettering explained.
then systems today would not have been vulnerable
IMHO the backdoor author(s) would have just targeted some other process/binary or targeted SSHD anyway via other mechanism as Poettering explained.
"Other people are vulnerable so our vulnerability doesn't matter" 🤦♂️
This is an example of how bloat and feature creep broadens the attack surface. Why should a daemon even link to a service manager specific library?
The https://github.com/openssh/openssh-portable/pull/375/commits/2e27b20733a1452c7fb6a06cae485ea559b45ccd part?
A standalone implementation that does not depend on libsystemd was merged on https://github.com/openssh/openssh-portable/commit/08f579231cd38a1c657aaa6ddeb8ab57a1fd4f5c
It has been brought to my attention that this breaks on non-glibc systems: https://github.com/void-linux/void-packages/blob/7363f7aa5bb16315672103af2a2227c9ff33bd2b/srcpkgs/openssh/patches/musl-connect.patch
It's not really much to do with this PR, but that's https://bugzilla.mindrot.org/show_bug.cgi?id=3707 and fixed in master already.
