Re: [PATCH v20] GSSAPI encryption support

Stephen Frost <sfrost@snowman.net> writes:

> * Robbie Harwood (rharwood@redhat.com) wrote:
>> Stephen Frost <sfrost@snowman.net> writes:
>>> * Robbie Harwood (rharwood@redhat.com) wrote:
>>>
>>>> Sure!  I'll go ahead and hack up the checks and lucid stuff and get
>>>> back to you.
>>>
>>> Great!  I'll finish fleshing out the basics of how to have this work
>>> server-side and once the checks and lucid stuff are in on the psql
>>> side, it should be pretty straight-forward to copy that same
>>> information into beentry alongside the SSL info, and expose it
>>> through pg_stat_get_activity() into a pg_stat_gss view.
>>
>> When the mech is gss_mech_krb5 under MIT krb5:
>>
>>     psql (12devel)
>>     GSSAPI encrypted connection (krb5 using aes256-cts-hmac-sha384-192)
>>     Type "help" for help.
>>
>> And the same under Heimdal:
>>
>>     psql (12devel)
>>     GSSAPI encrypted connection (krb5 using aes256-cts-hmac-sha1-96)
>>     Type "help" for help
>>
>> If the mech weren't gss_krb5, or Lucid introspection failed, but we're a
>> SASL-aware mech (and using MIT):
>>
>>     psql (12devel)
>>     GSSAPI encrypted connection (~256 bits)
>>     Type "help" for help.
>>
>> The third case (no lucid, no SASL SSF):
>>
>>     psql (12devel)
>>     GSSAPI encrypted connection (unknown mechanism)
>>     Type "help" for help.
>>
>> Feel free to tweak these strings as needed.
>
> That all looks fantastic!  Do you see any reason to not say:
>
>     GSSAPI encrypted connection (SASL SSF: ~256 bits)
>
> instead, since that's what we are technically reporting there?

Nope, that'd be fine with me!  (We'd probably want to get rid of the ~
in that case; I'd included it since SASL SSF is an approximate bit
measure, but 256 is the exact SSF.)

>> Another thing I've been thinking about here is whether the SASL SSF
>> logic is useful.  It'll only get invoked when the mechanism isn't
>> gss_mech_krb5, and only under MIT.  SPNEGO (krb5), NTLM
>> (gss-ntlmssp), IAKERB (krb5), and EAP (moonshot) all don't support
>> GSS_C_SEC_CONTEXT_SASL_SSF; I actually couldn't come up with another
>> mechanism that does.  I defer to you on whether to remove that,
>> though.
>
> Oh, hmm, I see.  Yeah, since there's no case where that could actually
> end up being used today then perhaps it makes sense to remove it- it's
> not a terribly good interface anyway since it doesn't provide the
> actual encryption algorithm, I had just gone down that route because I
> saw how to.  The lucid stuff is much better. :)
>
>> I've also adjusted the layering somewhat and moved the actual
>> printf() call down into fe-secure-gssapi.c I don't know whether this
>> model makes more sense in the long run, but for PoC code it was
>> marginally easier to reason about.
>
> No, I think we need to provide a way for libpq-using applications to
> get at that information easily..

Well, it's easier if there's only one type of thing (string) that can be
returned at least.  I imagine the interface there has to be pass
buffer-and-size into the function in fe-secure-gssapi.c then?  Do you
want me to make that change, or would you prefer to do it as part of the
server logging logic?

>> Patch attached after the break; apply on top of -20.
>
> Ok.  I'm pretty amazed at how little code it was to do..

The autotools part took the longest :)

> Is there somewhere that these functions are publicly documented and
> how they can be used from a GSSAPI handle is documented?

Not in the way you're hoping for, I suspect.  This interface is only
intended for consumption by NFS - which needs to pass contexts in and
out of the kernel.  Unlike GSSAPI, Kerberos5 interfaces aren't
standardized at all - parity between MIT and Heimdal is pretty low on
the krb5_*().

I was just referencing MIT's header files:
https://github.com/krb5/krb5/blob/master/src/lib/gssapi/krb5/gssapi_krb5.h#L229
(with the goal in mind of hitting krb5_enctype_to_name())
https://github.com/krb5/krb5/blob/master/src/include/krb5/krb5.hin#L6284-L6302

(Heimdal doesn't have any documentation/example code, but it works the
same way for lucid stuff; I had to look at the source to see how its
variant of krb5_enctype_to_string() worked.)

Thanks,
--Robbie