From: Robbie Harwood <rharwood@redhat.com>
To: Stephen Frost <sfrost@snowman.net>
Cc: pgsql-hackers@postgresql.org, Nico Williams <nico@cryptonector.com>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: David Steele <david@pgmasters.net>
Subject: Re: [PATCH v20] GSSAPI encryption support
Date: Fri, 22 Feb 2019 15:37:24 -0500
Message-ID: <jlgr2bza7az.fsf@redhat.com> (raw)
In-Reply-To: <20190221233910.GO6197@tamriel.snowman.net>
References: <jlg1tgq1ktm.fsf@thriss.redhat.com>
<jlgy38mir81.fsf@redhat.com>
<20190211125335.GN6197@tamriel.snowman.net>
<jlg7ee5zu0f.fsf@redhat.com>
<20190212014105.GO6197@tamriel.snowman.net>
<jlgwom4kerf.fsf@redhat.com>
<20190212191731.GS6197@tamriel.snowman.net>
<jlg36og4wbb.fsf@redhat.com>
<20190221233910.GO6197@tamriel.snowman.net>
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
Attachments:
signature.asc (application/pgp-signature, 832B) download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: rharwood@redhat.com, sfrost@snowman.net, nico@cryptonector.com, michael@paquier.xyz, alvherre@2ndquadrant.com, david@pgmasters.net
Subject: Re: [PATCH v20] GSSAPI encryption support
In-Reply-To: <jlgr2bza7az.fsf@redhat.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox