From owner-freebsd-security@freebsd.org Sat Dec 12 18:18:30 2020 Return-Path: Delivered-To: freebsd-security@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 578A94BC708 for ; Sat, 12 Dec 2020 18:18:30 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4CtbW86Y6Bz3kkN for ; Sat, 12 Dec 2020 18:18:28 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0BCIILJx027078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 12 Dec 2020 13:18:26 -0500 Date: Sat, 12 Dec 2020 10:18:21 -0800 From: Benjamin Kaduk To: Andrea Venturoli 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> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <08c18c5e-d0fe-16c2-dd17-af5162fd8716@netfence.it> X-Rspamd-Queue-Id: 4CtbW86Y6Bz3kkN X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of kaduk@mit.edu designates 18.9.28.11 as permitted sender) smtp.mailfrom=kaduk@mit.edu X-Spamd-Result: default: False [0.14 / 15.00]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[18.9.28.11:from]; RECEIVED_SPAMHAUS_PBL(0.00)[24.16.140.251:received]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:18.9.28.0/24]; NEURAL_SPAM_SHORT(0.43)[0.428]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[mit.edu]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_HAM_MEDIUM(-0.99)[-0.993]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3, ipnet:18.9.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; SUBJECT_HAS_QUESTION(0.00)[]; MAILMAN_DEST(0.00)[freebsd-security] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Dec 2020 18:18:30 -0000 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