Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kyx8f-0006Vv-28 for pgadmin-hackers@arkaria.postgresql.org; Mon, 11 Jan 2021 13:21:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kyx8d-0001y1-WF for pgadmin-hackers@arkaria.postgresql.org; Mon, 11 Jan 2021 13:21:40 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kyx8d-0001xh-1A for pgadmin-hackers@lists.postgresql.org; Mon, 11 Jan 2021 13:21:39 +0000 Received: from mail-ed1-x531.google.com ([2a00:1450:4864:20::531]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kyx8a-0000UV-BA for pgadmin-hackers@postgresql.org; Mon, 11 Jan 2021 13:21:38 +0000 Received: by mail-ed1-x531.google.com with SMTP id u19so18812051edx.2 for ; Mon, 11 Jan 2021 05:21:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgadmin.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WaZ1t9J94t9qX2zAadUdlwrYGVvfJWxztLdoPk3LwvA=; b=U41MLzLfQbahkY99hvRBsrqnvAdlsrdHS2G7rndKG01rwdNq52HnuIvl4TmdFHWgTz iIvR4kn+An09jilgj3qI0SsRUVQUXV+YfYb+DvJe1De63W6NwtV3+AieNlSRVSfIJCyq gWE1Pg4g6YQol0QmlS4kUqW1n8AYceul1TB/J9pcWK5wORm6vVw23M9V91aOFYOrajH+ bdEHWoy09wp9AsvIHTmFkxhntuxyFiZg5CaT2eiN3Om/COpBmlF5VLQl03vDqetgnqcY CeXoqSWIBoRvFleMaMWMeiDbFzNGIVPQwTMyv0fSrnPTL6HvWk1HPB1q3iAyUIF1W2kQ Aaew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WaZ1t9J94t9qX2zAadUdlwrYGVvfJWxztLdoPk3LwvA=; b=dA16LcxTH3RiiO5p2ASY1jxpB4sXbS6jw+YvYI2i9aZVm16gKe3APYQ7N3OzGY96cy vG9WaCqLpEVBtIsCbFI1Jo+xigQZOAqSKo11/ZHtToMgeYn8MIqiWT2Uj9fQ0F9RfLWt lQLA+iyXwQ+m248LrQqqrxsUOWgtgDsqztEPm5FpnBr1kdpglekM/p4pNN6z2WVe5Pbb OH+saLNoXpsoVtGbRJLRSEPDxW4EiZ7HUo81Q8pkuOKL0whxzpZW/cWHUn6W45oSWEgE sKkAzhUh8tCOyip9Nn+igpWRu/mQoYsKx+y7SjuBVKnGUzQcut9dfvw+MXJqIfg8vTRe k5Pg== X-Gm-Message-State: AOAM533kOeKYLgqj+AA9uqcdUF1ibrCrIA//ORCnhT+VDcSTumWTnZ/e DJ0VACmh4Moo6nSJ3GiU0XAwIKrsx5cK0uFHmVuDEA== X-Google-Smtp-Source: ABdhPJwha4/c0P6on0HqA9DjH3XpxPIHFF6kNBW6Ee1d9y7XUwsFbzMI/950CrcyiTNTxBut7b67eYLiWEegYE5iPcI= X-Received: by 2002:a50:d88c:: with SMTP id p12mr14081776edj.370.1610371294690; Mon, 11 Jan 2021 05:21:34 -0800 (PST) MIME-Version: 1.0 References: <20210102154130.GO27507@tamriel.snowman.net> <20210102155947.GQ27507@tamriel.snowman.net> <20210103173112.GR27507@tamriel.snowman.net> In-Reply-To: From: Dave Page Date: Mon, 11 Jan 2021 13:21:23 +0000 Message-ID: Subject: Re: [pgAdmin4][Patch] - RM 5457 - Kerberos Authentication - Phase 1 To: Magnus Hagander Cc: Stephen Frost , Khushboo Vashi , pgadmin-hackers Content-Type: multipart/alternative; boundary="000000000000fa123305b89fc891" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --000000000000fa123305b89fc891 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jan 11, 2021 at 1:15 PM Magnus Hagander wrote= : > On Sun, Jan 3, 2021 at 6:31 PM Stephen Frost wrote: > > > > Greetings, > > > > * Dave Page (dpage@pgadmin.org) wrote: > > > On Sat, 2 Jan 2021 at 15:59, Stephen Frost wrote= : > > > > * Dave Page (dpage@pgadmin.org) wrote: > > > > > On Sat, 2 Jan 2021 at 15:41, Stephen Frost > 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 t= o > 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 th= e > > > > > > delegated credentials are stored on the filesystem in a tempora= ry > > > > > > 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 t= o > 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= login > 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 cr= edentials, > > > > 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 passwor= d > to > > > > pgAdmin in some form that pgAdmin then turns around and impersonate= s > 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=E2=80=99t impersonate the user at all, it would just work a= s 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 unde= r 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. > Correct. > > 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? > Also correct - and right now, the plan is to disable password saving if logged in using Kerberos. --=20 Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EDB: http://www.enterprisedb.com --000000000000fa123305b89fc891 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jan 11, 2021 at 1:15 PM Magnu= s Hagander <magnus@hagander.net> wrote:
On= Sun, Jan 3, 2021 at 6:31 PM Stephen Frost <sfrost@snowman.net> wrote:
>
> Greetings,
>
> * Dave Page (dp= age@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) w= rote:
> > > > > > Please find the attached patch to support Ker= beros Authentication in
> > > > > > pgAdmin RM 5457.
> > > > > >
> > > > > > The patch introduces a new pluggable option f= or Kerberos
> > > authentication,
> > > > > > using SPNEGO to forward kerberos tickets thro= ugh a browser which will
> > > > > > bypass the login page entirely if the Kerbero= s Authentication
> > > succeeds.
> > > > >
> > > > > I've taken a (very short) look at this as it&#= 39;s certainly something that
> > > > > I'm interested in and glad to see work is bein= g done on it.
> > > > >
> > > > > I notice that 'delegated_creds' is being s= et 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_au= th_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 credenti= als can be found in
> > > > > the temporary file.=C2=A0 I don't see any of t= hat happening in this patch-
> > > is
> > > > > that already handled in some way?=C2=A0 If not, wh= at's the plan for making
> > > > > that work?=C2=A0 Also important is to make sure th= at this approach will work
> > > > > for constrainted delegation implementations.
> > > >
> > > > Phase 1 of this project (which this patch aims to imple= ment) 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 login 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 de= legated credentials,
> > > correct?
> > >
> > > Yes, though I sure hope there isn't a plan to release ju= st '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 impe= rsonates 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= 9;d probably be CVE
> > > worthy right out of the gate...
> >
> > It wouldn=E2=80=99t impersonate the user at all, it would just wo= rk as it does now,
> > requiring the user to supply a username/password for scram/md5/ld= ap etc, or
> > a cert for SSL auth. Connection to a PostgreSQL server which requ= ired gss
> > 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 th= is isn't
> actually real Kerberos support but is just an intermediate step that n= o
> 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.

Correct.
=C2=A0

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

Also correct = - and right now, the plan is to disable password saving if logged in using = Kerberos.=C2=A0

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twit= ter: @pgsnake

EDB: http://www.enterprisedb.com

--000000000000fa123305b89fc891--