freebsd security - Dec 2020 - Kerberos: base or port? [Was: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl]

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




> (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, ....).


  bye & Thanks
	av.

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 at 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