MIME-Version: 1.0
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>
 <20210103173112.GR27507@tamriel.snowman.net>
In-Reply-To: <20210103173112.GR27507@tamriel.snowman.net>
From: Magnus Hagander <magnus@hagander.net>
Date: Mon, 11 Jan 2021 14:15:00 +0100
Message-ID: 
 <CABUevEztMrWc9bxxDSL=1d8hCwPRu=HzM0wTLYBYoQwdQvKhzg@mail.gmail.com>
Subject: Re: [pgAdmin4][Patch] - RM 5457 - Kerberos Authentication - Phase 1
To: Stephen Frost <sfrost@snowman.net>
Cc: Dave Page <dpage@pgadmin.org>,
 Khushboo Vashi <khushboo.vashi@enterprisedb.com>,
	pgadmin-hackers <pgadmin-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Sun, Jan 3, 2021 at 6:31 PM Stephen Frost <sfrost@snowman.net> wrote:
>
> 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> wro=
te:
> > > > > * Khushboo Vashi (khushboo.vashi@enterprisedb.com) wrote:
> > > > > > Please find the attached patch to support Kerberos Authenticati=
on in
> > > > > > pgAdmin RM 5457.
> > > > > >
> > > > > > The patch introduces a new pluggable option for Kerberos
> > > authentication,
> > > > > > using SPNEGO to forward kerberos tickets through a browser whic=
h will
> > > > > > bypass the login page entirely if the Kerberos Authentication
> > > succeeds.
> > > > >
> > > > > I've taken a (very short) look at this as it's certainly somethin=
g 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 importan=
t 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 li=
bpq /
> > > > > the Kerberos libraries that the delegated credentials can be foun=
d in
> > > > > the temporary file.  I don't see any of that happening in this pa=
tch-
> > > is
> > > > > that already handled in some way?  If not, what's the plan for ma=
king
> > > > > that work?  Also important is to make sure that this approach wil=
l work
> > > > > for constrainted delegation implementations.
> > > >
> > > > Phase 1 of this project (which this patch aims to implement) is to =
handle
> > > > 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 l=
ogin 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 cred=
entials,
> > > 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 workin=
g
> > > 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...
> >
> > 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 g=
ss
> > or sspi simply wouldn=E2=80=99t work (unless the service account under =
which 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...

AIUI that's not what's being proposed.

Correct me if I'm wrong, but I think what's said is that this phase would:

1. Allow kerberos login *to pgadmin*.
2. Do exactly *nothing* to logins to the database server.

So per (2) logins to the db server would work exactly the same as it
does today, and bear no connection to the actual KRB login at all.

One question around that though -- when I click "save password" on a
database connection in pgadmin, it gets stored on the pgadmin server.
Isn't the key used to encrypt that derived from my password?  If I'm
logging into pgadmin without a password (using kerberos),what would
that key be derived from?

--=20
 Magnus Hagander
 Me: https://www.hagander.net/
 Work: https://www.redpill-linpro.com/