Date: Sun, 3 Jan 2021 12:31:12 -0500
From: Stephen Frost <sfrost@snowman.net>
To: Dave Page <dpage@pgadmin.org>
Cc: Khushboo Vashi <khushboo.vashi@enterprisedb.com>,
	pgadmin-hackers <pgadmin-hackers@postgresql.org>
Subject: Re: [pgAdmin4][Patch] - RM 5457 - Kerberos Authentication - Phase 1
Message-ID: <20210103173112.GR27507@tamriel.snowman.net>
References: 
 <CAFOhELdXhWMR2zS4dnH+SudN0s7LiENH+vczC0YhuifPgm+G5g@mail.gmail.com>
 <20210102154130.GO27507@tamriel.snowman.net>
 <CA+OCxozp+n+Mq+t=hPH1ExwT-MJbrhY0ujgkf+UoUriHo1PpGA@mail.gmail.com>
 <20210102155947.GQ27507@tamriel.snowman.net>
 <CA+OCxoydYmasD36n7Zk5_UPh9x03-QRqF53=sYbx3-rSYxPZsQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="bO/C3H35Ok2OdENj"
Content-Disposition: inline
In-Reply-To: 
 <CA+OCxoydYmasD36n7Zk5_UPh9x03-QRqF53=sYbx3-rSYxPZsQ@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk


--bO/C3H35Ok2OdENj
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Greetings,

* Dave Page (dpage@pgadmin.org) wrote:
> On Sat, 2 Jan 2021 at 15:59, Stephen Frost <sfrost@snowman.net> wrote:
> > * Dave Page (dpage@pgadmin.org) wrote:
> > > On Sat, 2 Jan 2021 at 15:41, Stephen Frost <sfrost@snowman.net> wrote:
> > > > * Khushboo Vashi (khushboo.vashi@enterprisedb.com) wrote:
> > > > > Please find the attached patch to support Kerberos Authentication=
 in
> > > > > pgAdmin RM 5457.
> > > > >
> > > > > The patch introduces a new pluggable option for Kerberos
> > authentication,
> > > > > using SPNEGO to forward kerberos tickets through a browser which =
will
> > > > > bypass the login page entirely if the Kerberos Authentication
> > succeeds.
> > > >
> > > > I've taken a (very short) look at this as it's certainly something =
that
> > > > I'm interested in and glad to see work is being done on it.
> > > >
> > > > I notice that 'delegated_creds' is being set but it's unclear to me=
 how
> > > > they're actually being used (if at all), which is a very important =
part
> > > > of Kerberos.
> > > >
> > > > What's commonly done with mod_auth_kerb/mod_auth_gss is that the
> > > > delegated credentials are stored on the filesystem in a temporary
> > > > directory and then an environment variable is set to signal to libp=
q /
> > > > the Kerberos libraries that the delegated credentials can be found =
in
> > > > the temporary file.  I don't see any of that happening in this patc=
h-
> > is
> > > > that already handled in some way?  If not, what's the plan for maki=
ng
> > > > that work?  Also important is to make sure that this approach will =
work
> > > > for constrainted delegation implementations.
> > >
> > > Phase 1 of this project (which this patch aims to implement) is to ha=
ndle
> > > Kerberos logins to pgAdmin when running in server mode (as we=E2=80=
=99ve already
> > > done for LDAP, except KRB authenticated users don=E2=80=99t see a log=
in page of
> > > course). Phase 2 will add support for logging into the PostgreSQL
> > servers -
> > > I believe that is where we=E2=80=99ll need to handle delegated creden=
tials,
> > correct?
> >
> > Yes, though I sure hope there isn't a plan to release just 'phase 1'
> > since that would imply that the user is still sending their password to
> > pgAdmin in some form that pgAdmin then turns around and impersonates the
> > user, basically completely against how Kerberos auth should be working
> > in this kind of a intermediate service arrangement.
> >
> > In other words, if just 'phase 1' is released, it'd probably be CVE
> > worthy right out of the gate...
>=20
> It wouldn=E2=80=99t impersonate the user at all, it would just work as it=
 does now,
> requiring the user to supply a username/password for scram/md5/ldap etc, =
or
> a cert for SSL auth. Connection to a PostgreSQL server which required gss
> or sspi simply wouldn=E2=80=99t work (unless the service account under wh=
ich the
> pgAdmin server is running has a valid ticket through other means).

That *is* impersonating the user..

Kerberized services really should *not* be accepting a cleartext
password to use to authenticate as the user against another service,
which is why I'd strongly recommend against releasing with just
'phase 1' done.. or at least heavily caveat'ing it that this isn't
actually real Kerberos support but is just an intermediate step that no
one should really deploy...

Thanks,

Stephen

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

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

iQIcBAEBCgAGBQJf8f9gAAoJEO1sijiDR2RVvWgQAKEN6AvOYrIp9x9EpZ6G2PiV
OQuXbpL/fWJ2O60VH33jpu2cOpgV5t60DbOkvSP51RJUuEZYAfTBVsnTCHN8yddJ
F5G7TykafGL8VlvaaYgfXHQGcxtaBPhUd7PHINtiTulJfbqw/ZmpSiLP5CWpKDVG
oMhu87lZUgmlRvOYpD7CiavOncdJTiTleesdgycp8B3rmlIlueOa3LrSXyI0AkQE
gk4Z4JBZMgff+MmRr04qVtfkLNAYC5nHMGXR2pYS2ZOai11KVQf6iMYBb/E+2Flg
EJIsy+X2EdqJaM/l7KRNB88CVjbygT1HF7tKjaGNJRuNmQWqfI2aTs4OkXdch4pr
Ol6kDZIbz16CFxkQQXaI9q/NBHL0ks9wBJ9DlzmYqLC5mOc4vuBsLs3+nbt3C605
ISZ0U/EBPqpFWVMLMEomPeykZByKhoEyM2NNTQVz89U8UqKW16mwqytHUO7L+N1K
Iq2MTCcfU/w3oYo1eGl5MB8I4DfugmGe59s3xAfipQEL5jlAIPzgwWyWAO6JPh7I
m5dHSjkg1aundRtAqGce/xxkN2yxb2Gbm7kXWoj4LUnRfcO154n/Wl7/yp5VaRM7
zfpR5BILqZ7gEAWJMXwVItK0WaW7xCZTOqmFZIbZ9WiXAFA0W3q2t4tGYyyTig5p
AgiEGKU9nNsZvBQLBLZ/
=UO2L
-----END PGP SIGNATURE-----

--bO/C3H35Ok2OdENj--