On ke, 06 marras 2019, Scott Schmit wrote:
On Mon, Nov 04, 2019 at 03:14:34PM +0100, Dario Lesca wrote:
Il giorno lun, 04/11/2019 alle 08.38 -0500, Neal Gompa ha scritto:
> What defines it as experimental?
https://wiki.samba.org/index.php/Running_a_Samba_AD_DC_with_MIT_Kerberos_KDC
> Using MIT Kerberos is still considered experimental.
I'd say you've buried the lede, as the rest at the link is much worse:
Samba 4.7 and later versions have shipped with code to support
building the Samba AD DC using MIT Kerberos. Since the time of the
release a number of issues, *including security issues*, have been
found by real-world use. However sadly the Samba Team has not been
able to resource the resolution of these issues to a standard that we
are happy with, and so Samba 4.9.3, 4.8.7 and 4.7.12 releases mark
this mode more clearly as experimental.
As an experimental feature, *we will not be issuing security patches*
for this feature, including for:
* S4U2Self crash with MIT KDC build
[emphasis mine] (That said, the linked-to crasher was fixed about 3.5
months after the report. I have no idea how that compares to typical
response times.)
I find that text worrying. Of course, all software has the potential
for vulnerabilities, and some software is better quality than other
software in general. Still, it's not hard to imagine people relying on
the security features in higher risk environments than they might
otherwise because "of course Fedora is using high quality security code"
and/or "it's Samba/MIT Kerberos, of course it's high quality" ... and
then it isn't.
From the wording above, it seems that Samba is no longer as confident as
they used to be that their MIT Kerberos integration is solid (i.e., they
weren't always calling it experimental), so they've (now) made the risks
explicit in their documentation. Fedora doesn't appear to be passing
that information along (yet).
The statement was made to make sure people who have no idea what various
backends within Samba mean don't create environments that cannot be
realistically supported by upstream right now.
There is ongoing work on making both MIT Kerberos and Samba to work
together properly in Samba AD DC environment. This work continues for
eight years already, sponsored by Red Hat, and shows the level of
complexity that we have to deal with.
To get you a bit of understanding where we are in this area, Isaac
Boukris found last year a number of security issues with Kerberos
implementations in Windows, MIT Kerberos, and Heimdal that basically
made all Active Directory implemenations broken:
- Local privilege escalation on Windows:
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-0734
- Unconstrained Kerberos S4U2Self delegation in Heimdal and Samba AD:
https://www.samba.org/samba/security/CVE-2018-16860.html
- Samba AD DC S4U2Self Crash in MIT Kerberos
https://www.samba.org/samba/security/CVE-2018-16853.html
- Reachable assertion in MIT Kerberos S4U2Self implementation before version 1.17
https://access.redhat.com/security/cve/cve-2018-20217
Isaac also added support for constraint-based resource delegation to MIT
Kerberos this year (https://github.com/krb5/krb5/pull/912) and is
working right now on fixing remaining S4U implementation details to
allow Samba AD DC with MIT Kerberos to be a thing. The latter spans to
both projects. A note: Heimdal implementation misses protocol
compatibility in this area by a long shot and Samba AD DC with Heimdal
does not behave correctly in quite a number of places. It ignores some
of the real checks required by the MS-KILE specification completely.
That's an easy thing to overlook -- I'm willing to assume that the Samba
project didn't send out an all points bulletin to all the distros
warning about it, but does it make sense to reconsider the default?
Maybe not, for all the reasons already stated. In that case, I'd say
the ethical thing would be to do *something* to make sure that users are
participating in the experiment with full knowledge of the risks.
I believe users have this information already since Fedora 29 release:
https://docs.fedoraproject.org/en-US/fedora/f29/release-notes/sysadmin/File_Servers/#_samba_ad_dc
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
