From nobody Thu Jul 31 16:06:27 2025 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4btDTz1jKbz640Rd; Thu, 31 Jul 2025 16:06:31 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta004.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4btDTy3ptPz3RTP; Thu, 31 Jul 2025 16:06:30 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of cy.schubert@cschubert.com designates 3.97.99.33 as permitted sender) smtp.mailfrom=cy.schubert@cschubert.com; dmarc=permerror reason="p tag has invalid value: quarantine rua=mailto:p[ostmaster@cschubert.com" header.from=cschubert.com (policy=permerror) Received: from shw-obgw-4004a.ext.cloudfilter.net ([10.228.9.227]) by cmsmtp with ESMTPS id hSZPu1eTi5MqyhVnZuV7eR; Thu, 31 Jul 2025 16:06:29 +0000 Received: from spqr.komquats.com ([70.66.136.217]) by cmsmtp with ESMTPSA id hVnYuXLcvJhBPhVnYuz0QG; Thu, 31 Jul 2025 16:06:29 +0000 X-Auth-User: cschuber X-Authority-Analysis: v=2.4 cv=QY3Fvdbv c=1 sm=1 tr=0 ts=688b9485 a=h7br+8Ma+Xn9xscxy5znUg==:117 a=h7br+8Ma+Xn9xscxy5znUg==:17 a=kj9zAlcOel0A:10 a=Wb1JkmetP80A:10 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=hEh3JUyyAAAA:8 a=zdPUvaFGAAAA:8 a=04oDvr9pAAAA:8 a=YxBL1-UpAAAA:8 a=icwiH-l0Uum8cQ8DvP4A:9 a=CjuIK1q_8ugA:10 a=LK5xJRSDVpKd5WXXoEvA:22 a=fvD0gfNcX4AKPV7IvcuC:22 a=sT4bYkpex2i6d5iwGOJT:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 9430F1E9; Thu, 31 Jul 2025 09:06:27 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 8E164214; Thu, 31 Jul 2025 09:06:27 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Rick Macklem cc: Cy Schubert , Benjamin Kaduk , Konstantin Belousov , Jessica Clarke , Cy Schubert , "src-committers@freebsd.org" , "dev-commits-src-all@freebsd.org" , "dev-commits-src-main@freebsd.org" Subject: Re: git: c7da9fb90b0b - main - KRB5: Enable MIT KRB5 by default In-reply-to: References: <202507211410.56LEAD6J066633@gitrepo.freebsd.org> <47C3CC37-6F32-4376-900A-B5387B9817D5@freebsd.org> <20250721144645.3BA391BE@slippy.cwsent.com> <20250722155941.AC7EB121@slippy.cwsent.com> <20250731152803.19F9ACD@slippy.cwsent.com> Comments: In-reply-to Rick Macklem message dated "Thu, 31 Jul 2025 08:53:16 -0700." List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-all@freebsd.org Sender: owner-dev-commits-src-all@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 31 Jul 2025 09:06:27 -0700 Message-Id: <20250731160627.8E164214@slippy.cwsent.com> X-CMAE-Envelope: MS4xfMpQhcnq6x/Ld7dmJ/lrT8SYlSC8Dap4XXbvGWVZDpViKNgrTYHqSFys3vJhivwugYJVfIFkbPoaN3gu+++z3cd6HGx970sCMhUGiNyd2NtjLdYqK5bX nBCOC7cfe+6WuZzOWUUcgDQE3cK/tjd6FBGjDIUm9C+vAvpAbVdkFc9JTyE51gwm49cgXbey/htpT8o9aMNt3pjiwHNi3M2I/I9Rbg15VPt7N97t6Uxtpcuf 0t8SKtST9gjFM4B5A5QZc0LCgqbCWRQzQOOX44Vr0Aol97OTUJsyZMxJrevaenepZBT8bpHfnDugiuvR02UuLulksd3QWysx0df6QUpMcG30X9H4L4wKl1v8 9u/hOyTVVbxbuDghyxE4atO1WYYChplwuS+2u9T+urBcf3CkNF9+8HB//vlV3mPtjvFoCYe/s2nBDwyQutndsmp/8Zd/nWEYs+L3ty7vy83yPEFIoOk= X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; MV_CASE(0.50)[]; RWL_MAILSPIKE_EXCELLENT(-0.40)[3.97.99.33:from]; R_SPF_ALLOW(-0.20)[+ip4:3.97.99.32/31]; RCVD_IN_DNSWL_LOW(-0.10)[3.97.99.33:from]; MIME_GOOD(-0.10)[text/plain]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_CC(0.00)[cschubert.com,gmail.com,freebsd.org]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; FREEMAIL_TO(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; DMARC_BAD_POLICY(0.00)[cschubert.com : p tag has invalid value: quarantine rua=mailto:p[ostmaster@cschubert.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US]; MLMMJ_DEST(0.00)[dev-commits-src-all@freebsd.org,dev-commits-src-main@freebsd.org]; RCPT_COUNT_SEVEN(0.00)[9]; R_DKIM_NA(0.00)[]; TAGGED_RCPT(0.00)[]; REPLYTO_EQ_FROM(0.00)[] X-Rspamd-Queue-Id: 4btDTy3ptPz3RTP X-Spamd-Bar: --- In message , Rick Macklem writes: > On Thu, Jul 31, 2025 at 8:28=E2=80=AFAM Cy Schubert com> wrote: > > > > In message ail.c > > om> > > , Rick Macklem writes: > > > On Thu, Jul 31, 2025 at 6:51=3DE2=3D80=3DAFAM Rick Macklem m@gmail.co=3D > > > m> wrote: > > > > > > > > On Thu, Jul 31, 2025 at 6:07=3DE2=3D80=3DAFAM Rick Macklem lem@gmail.=3D > > > com> wrote: > > > > > > > > > > On Wed, Jul 30, 2025 at 9:24=3DE2=3D80=3DAFPM Benjamin Kaduk sd@gmail.c=3D > > > om> wrote: > > > > > > > > > > > > On Wed, Jul 30, 2025 at 10:36=3DE2=3D80=3DAFAM Rick Macklem .macklem@g=3D > > > mail.com> wrote: > > > > > >> > > > > > >> On Mon, Jul 28, 2025 at 3:32=3DE2=3D80=3DAFPM Benjamin Kaduk kfbsd@gmai=3D > > > l.com> wrote: > > > > > >> > > > > > > >> > On Mon, Jul 28, 2025 at 3:04=3DE2=3D80=3DAFPM Benjamin Kaduk <= > bjkfbsd@gm=3D > > > ail.com> wrote: > > > > > >> >> > > > > > >> >> > > > > > >> >> Note that MIT krb5 provides the gss_krb5_export_lucid_sec_con= > text=3D > > > () API that does a lot of the work of getting useful bits out of an est= > abli=3D > > > shed GSS security context. > > > > > >> >> > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > And a bit more context on what is going on here and why kgssap= > i ha=3D > > > s to care: > > > > > >> > The GSS-API (RFC 2743) is all about a way to "establish a secu= > rity=3D > > > context" (i.e., do crypto negotiation, authentication, sometimes autho= > riza=3D > > > tion, etc.) between two entities, the initiator and the acceprot, and t= > hen =3D > > > exchanging protected messages between the two (which can be either encr= > ypte=3D > > > d or just integrity protection tags for otherweise cleartext data); lat= > er e=3D > > > xtensions included the ability to produce identical PRF output on both = > part=3D > > > ies, etc.. The details are "mechanism-specific", and for this purpose = > we'r=3D > > > e exclusively talking about the krb5 mechanism. The steps to establish= > the=3D > > > security context are complicated and sometimes fiddly, and in the gene= > ral =3D > > > case can require a large number of round-trips between the initiator an= > d ac=3D > > > ceptor before the security context is established. The individual mess= > age-=3D > > > protection parts are comparatively simple and amendable to implementati= > on i=3D > > > n the kernel for processing efficiency. > > > > > >> > RFC 2743 also defines functions for GSS_Export_sec_context() a= > nd G=3D > > > SS_Import_sec_context(), that are designed essentially to pass informat= > ion =3D > > > about an established security context from one process to another on th= > e sa=3D > > > me machine (which are presumably using the same implementation and vers= > ion =3D > > > of the implementation), so the contents of the exported blob are opaque= > and=3D > > > implementation-specific. We are abusing that mechanism to export info= > rmat=3D > > > ion about the security context that gssd has established and feed that = > info=3D > > > rmation into the kernel implementation of the per-message processing ro= > utin=3D > > > es. At present, this necessarily entails knowing the details of the im= > plem=3D > > > entation-specific opaque blob that is the "export sec context token", w= > hich=3D > > > is what the sys/kgssapi/krb5/krb5_mech.c code is doing. But if we can= > get=3D > > > the information we want without breaking the abstraction barrier, such= > as =3D > > > via the gss_krb5_export_lucid_sec_context() API, we are in a more robus= > t po=3D > > > sture overall and somewhat future-proofed against future evolution by M= > IT k=3D > > > rb5. > > > > > >> > (I note that recent Heimdal versions seem to also expose a gss= > _krb=3D > > > 5_export_lucid_sec_context() API, so part of the problem is just that t= > he H=3D > > > eimdal in base is so old.) > > > > > >> > > > > > >> Well, here's some "not so good" news... > > > > > >> I've been trying to use gss_inquire_sec_context_by_oid(..) with = > the =3D > > > oid > > > > > >> for the GSS_KRB5_EXPORT_LUCID_SEC_CONTEXT_OID with version 1. > > > > > >> It kept failing. > > > > > >> The problem seems to be that "gctx->proto =3D3D=3D3D 4" in make_= > external=3D > > > _lucid_ctx_v1() > > > > > >> function. This function only knows about the 0 and 1 setting for= > gct=3D > > > x->proto. > > > > > >> > > > > > >> Any ideas, rick > > > > > >> > > > > > > > > > > > > > > > > > > I'm not seeing anything to suggest that a "gctx->proto" value of = > 4 is=3D > > > ever expected; it looks like it's supposed to just be 0 (for the legac= > y RF=3D > > > C 1964 format) or 1 (for the "CFX" format of RFC 4121, with wider seque= > nce =3D > > > numbers for message-protection formats, etc.). So maybe it's worth pos= > ting=3D > > > your current WIP somewhere to take a closer look at what's going on. > > > > > > > > > > Yea, the debugging I did was flawed (I probably got the wrong offse= > t > > > > > in the structure). > > > > > It is weird, though. If I do gss_inquire_sec_context_by_oid(&minor,= > ctx=3D > > > , > > > > > OID_FOR_GSS_INQUIRE_SSPI_SESSION_KEY, &key), it > > > > > works and gives me the key and encryption type. > > > > > > > > > > If I do the same, but with the 12 byte OID for LUCID v1 (the 11 byt= > es f=3D > > > rom the > > > > > string + a 1 byte), it returns major =3D3D=3D3D GSS_S_COMPLETE, but= > no data=3D > > > and > > > > > a weird 39756046(decimal) or 0x25ea10e(hex) minor. > > > > > (Oh, and I tried gss_krb5_export_lucid_sec_context() and got the sa= > me > > > > > weird error.) > > > > --> Now (after doing a "make buildworld"), gss_krb5_export_lucid_sec_= > cont=3D > > > ext() > > > > returns GSS_S_BAD_MECH. Looking at the src, that error has to be= > fro=3D > > > m > > > > gss_inquire_sec_context_by_oid(). So, same function fails, but a= > dif=3D > > > ferent > > > > error return? > > > > > > > > It looks like "gssint_get_mechanism (ctx->mech_type)" is failing. > > > > I'm currently just passing GSS_C_NULL_OID into gss_init_sec_context()= > , > > > > but I've also tried the Kerberos 9 byte OID (both work, in the sense = > that > > > > gss_init_sec_context() seems to work, except that the actual_mech_typ= > e > > > > returned by it has a bogus pointer in the reply). > > > > --> It looks like the "mech_type" field of "ctx" is busted, for some = > reas=3D > > > on? > > > > > > > > I'm going to try building krb5 from ports and linking to that, to see= > if =3D > > > it > > > > does the same thing. > > > Finally some good news... > > > All I did was "pkg install krb5" and then linked the gssd to the librar= > ies =3D > > > in > > > /usr/local/lib and it worked!! > > > > gssapi/gssapi.h from krb5/lib/gssapi/generic is overwritten by our > > lib/libgssapi. As we have two the MIT gssapi.h is put in > > /usr/include/gssapi_krb5/gssapi.h. > > > > This patch should fix the problem. I haven't tested this yet. > > > > diff --git a/usr.sbin/gssd/Makefile b/usr.sbin/gssd/Makefile > > index 569e2c7e18f5..4c9d342c48c3 100644 > > --- a/usr.sbin/gssd/Makefile > > +++ b/usr.sbin/gssd/Makefile > > @@ -14,7 +14,7 @@ LIBADD=3D gssapi > > .if ${MK_MITKRB5} !=3D "no" > > # MIT KRB5 > > LIBADD+=3D krb5 k5crypto krb5profile krb5support > > -CFLAGS+=3D -DMK_MITKRB5=3Dyes > > +CFLAGS+=3D -DMK_MITKRB5=3Dyes -Iinclude/gssapi_krb5 > > .else > > # Heimdal > > LIBADD+=3D krb5 roken > Just to be clear to everyone, this might allow it to be built after > being patched for MIT, but it does not fix it so that it works. > > I will be debugging the patches that makes it works later to-day. > > You state that Heimdal didn't have a gssapi.h, but it does and it > has always been included in gssd.c. (It was the other ones like > gssapi_krb5.h, which needs the MIT gssapi.h.) /usr/include/gssapi/gssapi.h is installed by /usr/src/lib/libgssapi not by Heimdal v Using the port as an example, the gssapi.h MIT installs is not the same as the gssapi_krb5.h. include/Makefile installs include/gssapi/gssapi.h to /usr/include/gssapi/gssapi.h. Do we need this then? -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e**(i*pi)+1=0