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

On Fri, Dec 11, 2020 at 11:11:54AM +0100, Andrea Venturoli
wrote:
> On 12/10/20 12:03 AM, FreeBSD Security Advisories wrote:
> 
> > Note: The OpenSSL project has published publicly available patches for
> > versions included in FreeBSD 12.x.  This vulnerability is also known
to
> > affect OpenSSL versions included in FreeBSD 11.4.  However, the
OpenSSL
> > project is only giving patches for that version to premium support
contract
> > holders.  The FreeBSD project does not have access to these patches
and
> > recommends FreeBSD 11.4 users to either upgrade to FreeBSD 12.x or
leverage
> > up to date versions of OpenSSL in the ports/pkg system. The FreeBSD
Project
> > may update this advisory to include FreeBSD 11.4 should patches become
> > publicly available.
> 
> So I'm looking for suggestion on how to handle this.
> I guess I'll just upgrade some 11.4 to 12.2 and that'll be it.
> 
> However there are a few boxes I can't or don't want to upgrade and
I'm
> thinking about using openssl from ports.
> 
> 
> 
> If I'm correct, I'll need to put "DEFAULT_VERSIONS=
ssl=openssl" either
> in /etc/make.conf and/or in /usr/local/etc/poudriere.d/114amd64-make.conf.
> 
> I started with the latter, but a bulk run ended up in some port failing 
> (and a lot being skipped) due to kerberos support: AFAICT I cannot use 
> base's kerberos with ports' openssl. Which is a better replacement:
MIT
> or HEIMDAL?
It would be useful to give more specifics on the failures, as there's a few
classes of things that can go wrong.  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.  I
assume,
then, that you're running into API conflicts where hcrypto and libcrypto
present similar-named symbols, in which case MIT would be preferred.
(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.)

-Ben

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.