Date: Sat, 12 Dec 2020 10:18:21 -0800 From: Benjamin Kaduk <kaduk@mit.edu> To: Andrea Venturoli <ml@netfence.it> Cc: freebsd-security@freebsd.org Subject: Re: Kerberos: base or port? [Was: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl] Message-ID: <20201212181821.GO64351@kduck.mit.edu> In-Reply-To: <08c18c5e-d0fe-16c2-dd17-af5162fd8716@netfence.it> References: <20201209230300.03251CA1@freefall.freebsd.org> <0ccfbeb4-c4e1-53e6-81e8-112318cd9bf1@netfence.it> <20201211202315.GK64351@kduck.mit.edu> <08c18c5e-d0fe-16c2-dd17-af5162fd8716@netfence.it>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Dec 12, 2020 at 11:21:14AM +0100, Andrea Venturoli wrote:
> On 12/11/20 9:23 PM, Benjamin Kaduk wrote:
>
> > It would be useful to give more specifics on the failures, as there's a few
> > classes of things that can go wrong.
>
> I thought this would be OT in this thread, but I'll gladly comply :)
>
>
>
> > It doesn't look like openssl from
> > ports attempts to support the TLS ciphers with kerberos, which would rule
> > out the "openssl tries to depend on kerberos" class of issues.
>
> Not sure I understand (too much ignorance on my part).
>
>
>
> > I assume,
> > then, that you're running into API conflicts where hcrypto and libcrypto
> > present similar-named symbols
>
> Actually, I didn't get that far: /usr/ports/Mk/Uses/gssapi.ml just
> forbids compilation if using OpenSSL from ports and GSSAPI from base:
> > IGNORE= You are using OpenSSL from ports and have selected GSSAPI from base, please select another GSSAPI value
Ah, of course -- that's an easy one:
[bjk@kduck ~]$ ldd /usr/lib/libgssapi_krb5.so
/usr/lib/libgssapi_krb5.so:
libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x800693000)
libkrb5.so.11 => /usr/lib/libkrb5.so.11 (0x8006a0000)
libcrypto.so.111 => /lib/libcrypto.so.111 (0x801000000)
libroken.so.11 => /usr/lib/libroken.so.11 (0x800722000)
libasn1.so.11 => /usr/lib/libasn1.so.11 (0x800738000)
libcom_err.so.5 => /usr/lib/libcom_err.so.5 (0x8007de000)
libc.so.7 => /lib/libc.so.7 (0x800247000)
libcrypt.so.5 => /lib/libcrypt.so.5 (0x8012f4000)
libhx509.so.11 => /usr/lib/libhx509.so.11 (0x801315000)
libwind.so.11 => /usr/lib/libwind.so.11 (0x801366000)
libheimbase.so.11 => /usr/lib/libheimbase.so.11 (0x8007e3000)
libprivateheimipcc.so.11 => /usr/lib/libprivateheimipcc.so.11 (0x8007ea000)
libthr.so.3 => /lib/libthr.so.3 (0x801391000)
(Note the dependency on libcrypto.)
Having two different instances of libcrypto in the same address space is
generally asking for trouble (though it is possible to do safely, with
sufficient care to detail). Having the ports collection just forbid that
outright seems like the right choice to me -- I had just forgotten that
heimdal even had the option to use openssl libcrypto instead of its own
libhcrypto.
> Now that I know there are patches for 11.4, I hope I'm not going to need
> OpenSSL from ports, so this is losing interest for me.
Understood. Thanks for following up anyway!
>
>
>
> > (The heimdal in base is quite old anyway, and using an external kerberos
> > would be recommended in general if you're using it for much.)
>
> This is an interesting statement.
> I barely know what Kerberos is: granted, I know what it was designed for
> and what it provides, but for me it's more or less just a dependency of
> Samba and related software.
>
> My uses cases are:
> _ Samba AD DC;
> _ Samba AD member file server;
> _ various ways of authenticating against Samba (winbindd, pam_ldap,
> nss_ldap, saslauthd, etc...);
> _ kerberizing NFSv4 has been in my todo list for a while (but with too
> low priority for now :)
>
> In spite of everything working, should I abandon Heimdal from base? For
> Heimdal from ports?
> (Consider Samba is using it's own bundled Heimdal, so this would be for
> pam_ldap, nss_ldap, saslauthd, ....).
None of those quite seem like they qualify as being complicated uses, so
there is probably not much immediate benefit from switching, for you.
I was thinking more of issues like
https://github.com/pythongssapi/python-gssapi/issues/228 relating to use of
"advanced features" that have been only been added/specified comparatively
recently.
Sorry to have been a little too sensationalist, there.
-Ben
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20201212181821.GO64351>