[prev in list] [next in list] [prev in thread] [next in thread] 

List:       debian-devel
Subject:    Re: Debian openssh option review: considering splitting out GSS-API key exchange
From:       Christian_Göttsche <cgzones () googlemail ! com>
Date:       2024-04-02 10:25:30
Message-ID: CAJ2a_De4vc58g_b-kbDcF7COpdogjO3bb66ihZtP242L5py5fg () mail ! gmail ! com
[Download RAW message or body]

On Tue, 2 Apr 2024 at 02:30, Colin Watson <cjwatson@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)                              [cjwatson@debian.org]
>

[prev in list] [next in list] [prev in thread] [next in thread]