From nobody Thu Jul 31 15:53:16 2025 X-Original-To: dev-commits-src-main@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 4btDC44XSPz63ysv; Thu, 31 Jul 2025 15:53:36 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4btDC40t16z3Q62; Thu, 31 Jul 2025 15:53:36 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-615a115f0c0so1034449a12.0; Thu, 31 Jul 2025 08:53:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1753977209; x=1754582009; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=qGdXSB5NbUeUkvbQFXm8nUdxOTaQw8yjpc3xdmNPEPE=; b=EmP1x4p/k/l55XnAchSDzL/XqAclKHw44AOuKVsOrekzb5LGKIrZiinhymmhs1dZNc zTD9BEE5tlgpQt0VmKE7Cy+3oyuCnS0IcEbk4UCukzGEqGwIAXLyIif497ZflsLAVoBy d/5wkLYgncaiSPKs2uNFU6v1T0QxI9dyNAzy5vORhv5aEHKkcH5Df/ha++F9PvrtZGBv 6sIXZBUh7RHqBHhkidJDDfVUYyY3PabMKZVisgyb0EVdYkGI+T/SqxDgIsPpKCE6f9da HR1lJflheThZ188gp5uW1b/62Tbr268EIUGPdFKtuOKlWyZxHXW2wpG5BWy+gNgWAKSL owcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753977209; x=1754582009; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=qGdXSB5NbUeUkvbQFXm8nUdxOTaQw8yjpc3xdmNPEPE=; b=nEKNTHqLLx7gfAXy55goTsT31aJ2IaE3d0BYCfn+6d0Q0KAPaf2qIMTZhMVTVEll76 TRdQf2+mdLJc1dPXU4O6uwSoZIP1zJoH5XpyivqY1yeLgXLiH1ZtGd9mqwf8+b9w1Nvo hiI6K4JPeUuciXMqPKICxicpeViLp6JfT8aWDxExfom4/vZiBzBavqYIK4R9X3RNPSI8 2WVgDdgHH8kbi6szoaoMv8eyab4dR06sTx4kUMau02N8P0viMdaySnGzsk0d7ZyhNXOY moclFNJQfUYH0j5F8rTv7UsUkcXgVZSGJCtsPuVgY9UG+m63yY4cwZtKGMqbpbh7J1cm W/7g== X-Forwarded-Encrypted: i=1; AJvYcCUDtC9u2z0SMVU7GLeSh6h3GKhKmMmwK3KIwP31EEDJXLtdHDqkr3DunrscmjElo/RtTL3JxMXL@freebsd.org, AJvYcCUVg+tsxiwJflPSbr7R2Kk70L+vvaLd7MduAXAFs22lUCZxoh4MkBYPyawsTX0ITS7KY9P2+hkJBR8ONB8B3BQDzbR/og==@freebsd.org, AJvYcCV7KxgIxuosFRN27vCPECQe6hTys8h6dB7YbHt4PY6h/GbppI4QdxZSaGiW5uQ5C5JtAeZmcIr/33sHPZ6T/PXiZ1wI88g=@freebsd.org, AJvYcCVKCkVI7t+FsP9qxzAYNGu5t7DAWZNAZd+5yiRuE9E0uf0haKuf+XCRI7Sbh31Fc8fY+w==@freebsd.org, AJvYcCXvuLGRRZUTMnuG/EVH0Uhx5qMjYTpo2LY4YYlWIabZuTQ8JKiMAfE8zy/qVhPph2NfT96e7yFhnoustIJzJB4=@freebsd.org X-Gm-Message-State: AOJu0Yzd6NGpdKawF20BRa9ugAMr95GidvEPu8KqyMmFd+GDSPbaG9eZ 7o6kPUV4AQfTuTgnsNbgETgHI5kLLzIVVRDpmzw3z4nREwB+XUK85J2P3ibMu9MvXvdO8iY7vcE 2NhT8Mo547XRy7njPzgQOJ5Lu4tA3oA== X-Gm-Gg: ASbGncuNtHsRpAm5NCd4wO9Rq+vFvRX9YPKh8iMGYFXAHKNplaBhptXa8azfAPXXAtn h3rMpW72+Lgh9+upsF8/lKivOyNDpNzhntIrWJqByprWJ1jExc7CRgygBEQ9317rlcV/a5pgJnW uPFyZ128XK/50Z0PVuCMpBKZFHvQWnYGZhbhEcopURxlWY9jyPTsVE9qb75Ew99AIGRgQq+PcsH fHdSxe5fKtU9ziKbgHuGI370phlu9sS27YjnEE= X-Google-Smtp-Source: AGHT+IGNoXZOJqcSe8v8y1fPRM0cxC6wiW6gHK2Ww0mRwkx511k+JO2XAarI+r6TDEVCiRGMsKz5C/iF7TD17d5zrRk= X-Received: by 2002:a05:6402:2106:b0:615:9b4e:7b93 with SMTP id 4fb4d7f45d1cf-6159b4e8017mr5627604a12.30.1753977208933; Thu, 31 Jul 2025 08:53:28 -0700 (PDT) List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-main@freebsd.org Sender: owner-dev-commits-src-main@FreeBSD.org MIME-Version: 1.0 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> In-Reply-To: <20250731152803.19F9ACD@slippy.cwsent.com> From: Rick Macklem Date: Thu, 31 Jul 2025 08:53:16 -0700 X-Gm-Features: Ac12FXxpc-_GZUSZMOceOK8275ryTaZqVoskwgv1WXFG52InmZj2GlSGKvJEq-w Message-ID: Subject: Re: git: c7da9fb90b0b - main - KRB5: Enable MIT KRB5 by default To: Cy Schubert Cc: Benjamin Kaduk , Konstantin Belousov , Jessica Clarke , Cy Schubert , "src-committers@freebsd.org" , "dev-commits-src-all@freebsd.org" , "dev-commits-src-main@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4btDC40t16z3Q62 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] On Thu, Jul 31, 2025 at 8:28=E2=80=AFAM Cy Schubert wrote: > > In message om> > , Rick Macklem writes: > > On Thu, Jul 31, 2025 at 6:51=3DE2=3D80=3DAFAM Rick Macklem > m> wrote: > > > > > > On Thu, Jul 31, 2025 at 6:07=3DE2=3D80=3DAFAM Rick Macklem > com> wrote: > > > > > > > > On Wed, Jul 30, 2025 at 9:24=3DE2=3D80=3DAFPM Benjamin Kaduk > om> wrote: > > > > > > > > > > On Wed, Jul 30, 2025 at 10:36=3DE2=3D80=3DAFAM Rick Macklem > mail.com> wrote: > > > > >> > > > > >> On Mon, Jul 28, 2025 at 3:32=3DE2=3D80=3DAFPM Benjamin Kaduk > 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.) rick > > > > > > Now I can test/debug the changes. > > > > Btw, the stuff in /usr/local/include/gssapi are correct and not messed = up > > like the stuff in /usr/include/gssapi. (The ones in /usr/local/include = defi=3D > > ne > > GSS_DLLIMP for example.) > > > > I'm going to leave figuring out why the libraries in /usr/lib are messe= d up > > to someone else. > > > > rick > > > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: https://FreeBSD.org > NTP: Web: https://nwtime.org > > e**(i*pi)+1=3D0 > >