On Sun, 3 Jan 2021 at 17:31, Stephen Frost <sfr...@snowman.net> wrote:
> Greetings, > > * Dave Page (dp...@pgadmin.org) wrote: > > On Sat, 2 Jan 2021 at 15:59, Stephen Frost <sfr...@snowman.net> wrote: > > > * Dave Page (dp...@pgadmin.org) wrote: > > > > On Sat, 2 Jan 2021 at 15:41, Stephen Frost <sfr...@snowman.net> > wrote: > > > > > * Khushboo Vashi (khushboo.va...@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 > 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
