Re: [pgAdmin4][Patch] - RM 5457 - Kerberos Authentication - Phase 1

public inbox for [email protected]  
help / color / mirror / Atom feed

From: Dave Page <[email protected]>
To: Stephen Frost <[email protected]>
Cc: Khushboo Vashi <[email protected]>
Cc: pgadmin-hackers <[email protected]>
Subject: Re: [pgAdmin4][Patch] - RM 5457 - Kerberos Authentication - Phase 1
Date: Mon, 4 Jan 2021 11:32:50 +0000
Message-ID: <CA+OCxozmK1wrzNaso3LhVGmpCenWTk6PzOKSYYAX2AnVykUviQ@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CAFOhELdXhWMR2zS4dnH+SudN0s7LiENH+vczC0YhuifPgm+G5g@mail.gmail.com>
	<[email protected]>
	<CA+OCxozp+n+Mq+t=hPH1ExwT-MJbrhY0ujgkf+UoUriHo1PpGA@mail.gmail.com>
	<[email protected]>
	<CA+OCxoydYmasD36n7Zk5_UPh9x03-QRqF53=sYbx3-rSYxPZsQ@mail.gmail.com>
	<[email protected]>

On Sun, 3 Jan 2021 at 17:31, Stephen Frost <[email protected]> wrote:

> Greetings,
>
> * Dave Page ([email protected]) wrote:
> > On Sat, 2 Jan 2021 at 15:59, Stephen Frost <[email protected]> wrote:
> > > * Dave Page ([email protected]) wrote:
> > > > On Sat, 2 Jan 2021 at 15:41, Stephen Frost <[email protected]>
> wrote:
> > > > > * Khushboo Vashi ([email protected]) 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
> libpq /
> > > > > the Kerberos libraries that the delegated credentials can be found
> in
> > > > > the temporary file.  I don't see any of that happening in this
> patch-
> > > is
> > > > > that already handled in some way?  If not, what's the plan for
> making
> > > > > 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
> handle
> > > > Kerberos logins to pgAdmin when running in server mode (as we’ve
> already
> > > > done for LDAP, except KRB authenticated users don’t see a login page
> of
> > > > course). Phase 2 will add support for logging into the PostgreSQL
> > > servers -
> > > > I believe that is where we’ll need to handle delegated credentials,
> > > 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...
> >
> > It wouldn’t 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’t 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...


By that argument, one should not be able to login to a kerberised SSH
server and then use a mail client to access Gmail (or for that matter, the
web interface), neither should one be able to login to a Postgres server
using Kerberos, and then use a non-kerberised FDW.

Why aren’t those cases CVE worthy?
-- 
-- 
Dave Page
https://pgsnake.blogspot.com

EDB Postgres
https://www.enterprisedb.com

view thread (32+ messages)  latest in thread

reply

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: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: [pgAdmin4][Patch] - RM 5457 - Kerberos Authentication - Phase 1
  In-Reply-To: <CA+OCxozmK1wrzNaso3LhVGmpCenWTk6PzOKSYYAX2AnVykUviQ@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox