Date: Thu, 21 Feb 2019 18:39:10 -0500
From: Stephen Frost <sfrost@snowman.net>
To: Robbie Harwood <rharwood@redhat.com>
Cc: pgsql-hackers@postgresql.org, Nico Williams <nico@cryptonector.com>,
	Michael Paquier <michael@paquier.xyz>,
	Alvaro Herrera <alvherre@2ndquadrant.com>,
	David Steele <david@pgmasters.net>
Subject: Re: [PATCH v20] GSSAPI encryption support
Message-ID: <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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="fL5uibfitsvsbG47"
Content-Disposition: inline
In-Reply-To: <jlg36og4wbb.fsf@redhat.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk


--fL5uibfitsvsbG47
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Greetings,

* 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.
>=20
> When the mech is gss_mech_krb5 under MIT krb5:
>=20
>     psql (12devel)
>     GSSAPI encrypted connection (krb5 using aes256-cts-hmac-sha384-192)
>     Type "help" for help.
>=20
> And the same under Heimdal:
>=20
>     psql (12devel)
>     GSSAPI encrypted connection (krb5 using aes256-cts-hmac-sha1-96)
>     Type "help" for help
>=20
> If the mech weren't gss_krb5, or Lucid introspection failed, but we're a
> SASL-aware mech (and using MIT):
>=20
>     psql (12devel)
>     GSSAPI encrypted connection (~256 bits)
>     Type "help" for help.
>=20
> The third case (no lucid, no SASL SSF):
>=20
>     psql (12devel)
>     GSSAPI encrypted connection (unknown mechanism)
>     Type "help" for help.
>=20
> 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?

> 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..

> 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 did some testing with Heimdal since we're using some extensions here,
> and found out that the current build machinery doesn't support Heimdal.

Hah!

> (The configure.in detection logic only seems to work for MIT and
> Solaris.)  However, it's possible to explicitly pass in CFLAGS/LDFLAGS
> and it worked prior to my changes, so I've preserved that behavior.

Alright.  That seems like an independent change, if we decide to make
it easier for people to build with heimdal, but there hasn't been much
call for it, clearly.

> Finally, as this patch touches configure.in, configure needs to be
> regenerated; I'm not sure what project policy is on when that happens
> (and it produces rather a lot of churn on my machine).

There's some magic there due to vendor changes to autoconf, as I recall,
which is likely why you're seeing a lot of churn.

> Patch attached after the break; apply on top of -20.

Ok.  I'm pretty amazed at how little code it was to do..  Is there
somewhere that these functions are publicly documented and how they can
be used from a GSSAPI handle is documented?

Thanks a lot for this work!

Stephen

--fL5uibfitsvsbG47
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJcbzaeAAoJEO1sijiDR2RVCtcP+wV3+Ci8KECXTXzSwvF1uGEw
dVE9ID5VDk2Q79iG93WdZBTNnXIxyom1MLHmFXlD0NyX6mwEUq6m8MRozFvTKYSf
i/sdMbNAjHB60BDUiy2DKZDNRR+Yn/TF2b+LaNeVX0mBkw3v50aeO1dAGIGxoU+S
eyI9k4DsfQrsMtJhakpJ0J12dRq9BONBiDzg50W0wcNg2wjt3bLqS3taExj8ntxZ
PEf/CJ1NhAhc9rNrl7yPga6R3h9VbpCckN56/vExE9IzqFtal81mPNrDpv3vmtit
WDHpuQErw9jpFQklLmOLfuNfY4i1tL6YPYgJK+8cmWtjF9Jm/Z27ASpDcWR3QW97
mMajq53Zp4Ort43jtZqTImELH0RbIVUswwls4NM4xjOoZsvYNSKt22lSnCbY6ZTQ
kSIUPiRYDfI5/zkLa2lrO/Lz+p+4e3zyTAmWdonvPGr70cIDUAnOZUY5L8wRHItd
qk6wOYY/RVn4WJKpFws92AggUhnxNVIBZFdxueR06BlchYOP4pTSBbnZbu1bizYx
sSt8JjI9y2LAw1P6nopK4tvycftQUzMF4jPeZiztjt5S9OJzxOzR3Y7YsFKQ04Y7
Uay5Gyr+DY3kEjn+iQzKfHEZald1UrfEOV/ZnPuntkv4Kne3BW21pi4oo6Dmzl/H
fQhNYyAU3I8YH+RwtVK8
=+/o7
-----END PGP SIGNATURE-----

--fL5uibfitsvsbG47--