Anyone managed to build a static gssd?

[Rick Macklem]

Benjamin Kaduk wrote:
>On Sun, Jan 07, 2018 at 01:28:10AM -0500, Garrett Wollman wrote:
>> I'm interesting in experimenting with GSSAPI security for NFS mounts,
>> but we run MIT Kerberos, not Heimdal.  AIUI, the kernel code has to
>> have the same data structures as the userland code in gssd, which
>> implies that gssd has to be built against Heimdal libraries, not MIT.
>
>I think you might want to test that hypothesis experimentally --
>both Heimdal and MIT have gss_export_lucid_sec_context() that
>generate the gss_krb5_lucid_context_v1_t data type, which seems
>to be defined identically between them.  AIUI, this "lucid" (i.e.,
>non-opaque) type is what is used for sending the GSS information
>into the kernel.
I haven't worked with this for a long time, but I vaguely recall that
the kernel RPCSEC_GSS code uses a relatively small subset to the
KGSSAPI upcalls to userland.

If you grep around in sys/rpc/rpcsec_gss you should be able to find
which ones they are (and see if they happen to be the same for Heimdal/MIT).
I think the client side uses more than the server side, but beware that
the server becomes a client for callbacks for NFSv4.

Also, just fyi, RPCSEC_GSS Version 1 (the only one supported by FreeBSD)
uses good old DES and uses the session key created by the Kerberos
libraries via a TGT or keytab entry for this.
--> As such, your TGT encryption choice must result in a 56/64 bit session key.
     (I never went beyond using DES for TGT encryption, but I suspect MIT
      doesn't like that idea;-)

Good luck with it, rick