On Tue, 2 Apr 2024 at 02:30, Colin Watson <cjwat...@debian.org> wrote: > > [I've CCed openssh-unix-dev for awareness, but set Mail-Followup-To to > just debian-devel and debian-ssh to avoid potentially spamming them with > a long discussion. If you choose to override this then that's your > call, but please be mindful of upstream's time.] > > Following the xz-utils backdoor, I'm reconsidering some choices in > Debian's OpenSSH packaging. Please note that significant rearchitecture > of the upstream code is out of scope for the Debian packaging, so I'm > going to disregard comments of the form "maybe there should be a module > loader so all these things can just be plug-ins" or other such blue-sky > things; from my point of view this is just about configuring things a > bit more wisely within more or less our current constraints. > > > libsystemd > ========== > > This is the obvious thing on everyone's mind right now. At the time I > merged that patch, "not NIHing code that's in a perfectly good library" > seemed like a reasonable trade-off, but we do seem to have ended up on > the wrong side of history on this one. There's work in progress to land > readiness protocol notification upstream without libsystemd (thanks > Damien and Luca!), and I expect to cherry-pick this into Debian once > it's agreed, so we'll get rid of that linkage and reduce our patch load > a bit. > > We also have a patch from Ubuntu to support the systemd socket > activation protocol. I've rewritten this to avoid using libsystemd, and > I'll submit it upstream once the readiness notification work is sorted > out. But it's not particularly invasive once the libsystemd linkage is > removed, so it's not the end of the world if this ends up staying in our > patch queue. > > > GSS-API key exchange > ==================== > > Way back in 2005, I merged the GSS-API key exchange patch into Debian's > main openssh package (https://bugs.debian.org/275472). At the time it > seemed like a sensible overall reduction in maintenance burden (if I > remember correctly, the openssh-krb5 package often ended up lagging a > fair bit behind openssh). While the patch is fairly large, it hasn't > generally been too hard to forward-port to newer versions of OpenSSH, > and Fedora carries it too so there's some sharing of work. > > However, OpenSSH upstream has long rejected it, mainly on the basis that > they don't like adding new pre-authentication attack surface, and this > week seems like a good one to reconsider what patches we're shipping by > default. gssapi.patch is the largest patch in our openssh package by an > order of magnitude, and easily the most intrusive in terms of complexity > and exposure, so I've somewhat regretted my choice to merge it a few > times over the years. > > All the same, I'm aware that some people now depend on having this > facility in Debian's main openssh package: I get enough occasional bug > reports to convince me that it's still in use. So, if I decide to split > it back out, I'd want to arrange for a somewhat graceful transition. > We've had it for nearly 20 years now, so we can take the time to do a > proper job that at least tries not to leave users in the lurch. > > How does this rough plan sound? > > * for Debian trixie (current testing): > > * add dependency-only packages called something like > openssh-client-gsskex and openssh-server-gsskex, depending on their > non-gsskex alternatives > * add NEWS.Debian entry saying that people need to install these > packages if they want to retain GSS-API key exchange support > * add release note saying the same > > * for Debian trixie+1 (or maybe after the next Ubuntu LTS, depending on > exact timings): > > * add separate openssh-gsskex source package, carrying gssapi.patch > in addition to whatever's in openssh, and whose binary packages > Conflicts/Replaces/Provides the corresponding ones from openssh > * add some kind of regular CI to warn about openssh-gsskex being out > of date relative to openssh > * drop gssapi.patch from openssh, except for small patches to > configuration file handling to accept the relevant options with > some kind of informative warning (compare > https://bugs.debian.org/152657) > > I guess we should decide whether the separate packages are to be needed > for GSS-API authentication as well as key exchange, because that affects > the choice of dependency-only package names in trixie. If we only split > out gssapi.patch (for key exchange; sorry about the slightly misleading > name) but kept --with-kerberos5 (which also controls authentication), > then we'd significantly reduce our patch load but not sshd's linkage. > > I've seen the suggestion of using libgssglue here > (https://fosstodon.org/@jas/112194876950058188). That might be a good > idea and I have no particular objection to it, though I also don't know > much about it and it would probably be better if an expert did the work. > Perhaps it would make continuing to build the default variant using > --with-kerberos5 more palatable, since then the extra non-trivial > linkage would only affect people who turn on those options. > > > TCP wrappers > ============ > > We carry a patch to restore support for TCP wrappers, which was dropped > in OpenSSH 6.7 (October 2014); see > https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-April/032497.html > and thread. That wasn't long before the Debian 8 (jessie) freeze, and > so I patched it back in "temporarily", but then I dropped the ball on > organizing a proper transition. libwrap links to libgssapi_krb5 (via > libnsl and libtirpc), so if we want to do a proper job of removing that > linkage then we'll have to finish this transition too. This probably > means a similar timeline, with the addition that people will have to > make sure that they aren't relying on /etc/hosts.deny being effective > for sshd. > > At the time, denyhosts was popular, but it was removed from Debian > several years ago. I remember that, when I dealt with that on my own > systems, fail2ban seemed like the obvious replacement, and my impression > is that it's pretty widely used nowadays; it's very pluggable but it > normally works by adding firewall rules. Are there any similar popular > systems left that rely on editing /etc/hosts.deny? > > Fedora dropped libwrap from sshd in 2018 > (https://bugzilla.redhat.com/show_bug.cgi?id=1530163), and > https://fedoraproject.org/wiki/Changes/Deprecate_TCP_wrappers has some > other options here (which would need to be adapted for Debian, but > broadly similar approaches would work). > > > SELinux > ======= > > The fact that we build using --with-selinux has come up > (https://cybervillains.com/@djm/112192735215160932).
This is actually wrong, libselinux does not link to liblzma. Someone did a short look on the build dependencies on Fedora, which include as a leftover xz-utils due to a previous patch adding supporting for lzma. > I haven't formed a > complete opinion on this, but I'm less worried about this linkage than > about GSS-API: it doesn't need much in the way of complex OpenSSH > patches, and the idea that it links indirectly to liblzma seems to have > been a mistaken one that turned up early in the discussions around the > xz-utils backdoor. > > My feeling on this is that it's probably of about as much concern as > PAM, which we're definitely stuck with enabling, and I'm not > enthusiastic about adding a matrix of variant packages. We could go for > something like openssh-{client,server}-full, but I'm not clear that > there's much in the way of correlation between people who need GSS-API > key exchange and people who need SELinux support, and I don't want to > force more people than necessary onto the variant that includes an extra > 4000-odd-line patch. > > For the time being my inclination is to leave this be, but I've seen the > suggestion that pam_selinux is basically all you need > (https://infosec.exchange/@alwayscurious/112192949171400643), so maybe > it would be an option to drop --with-selinux in favour of that? I've > never used SELinux, so I'd need an expert to weigh on here. Maybe this opportunity can be used to try together with the Fedora/RHEL packaging team to unify and upstream all the SELinux related patches: * https://sources.debian.org/src/openssh/1:9.7p1-3/debian/patches/selinux-role.patch/ * https://src.fedoraproject.org/rpms/openssh/blob/rawhide/f/openssh-6.6.1p1-selinux-contexts.patch * https://src.fedoraproject.org/rpms/openssh/blob/rawhide/f/openssh-6.6p1-privsep-selinux.patch * https://src.fedoraproject.org/rpms/openssh/blob/rawhide/f/openssh-7.8p1-role-mls.patch > > > Comments welcome, > > -- > Colin Watson (he/him) [cjwat...@debian.org] >