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 1kwO6o-00023k-33 for pgadmin-hackers@arkaria.postgresql.org; Mon, 04 Jan 2021 11:33:10 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kwO6m-00036f-8e for pgadmin-hackers@arkaria.postgresql.org; Mon, 04 Jan 2021 11:33:08 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kwO6l-00036Y-O1 for pgadmin-hackers@lists.postgresql.org; Mon, 04 Jan 2021 11:33:08 +0000 Received: from mail-ej1-x62f.google.com ([2a00:1450:4864:20::62f]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kwO6g-0000gr-Ht for pgadmin-hackers@postgresql.org; Mon, 04 Jan 2021 11:33:06 +0000 Received: by mail-ej1-x62f.google.com with SMTP id jx16so36314231ejb.10 for ; Mon, 04 Jan 2021 03:33:02 -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=p3EqQkO91tEayzYzdrCUmCydwhqAT+imx7Ni93CnIyE=; b=Y9qLb1dO+NzxB+SvokBZtUqYamUlq1GU3vuqhb7hH/kNDspNzz7/YYKczwF9dB/Ua7 Ebt+Xa1v2MMUBpZXarKlr+oUzmWgrEz06D8yEI5izJXJ4Rm+z5E0jDLoPJl7S3ZaEGC3 cMKUCqB+ZSKVygrCTGtQ4249VvGxcmwbfPiNo27HSsiV7ZjiWNy1vcfljM88R9v2j9Id oIcX19sktYD3ReKJEP8A6YRsOBWWsRdFgkeMT9Dk4U6pzBh1/givXfhn91+wMwk0VRer CKfupyLXw6tusPQw3aWjpheW0NzdDJmOI83SBL7sehYpySwG5DL1l2zEfn6oHEEBFY65 ISww== 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=p3EqQkO91tEayzYzdrCUmCydwhqAT+imx7Ni93CnIyE=; b=llXkOgYqlCClqLuEc+0/h5pUV5hccmJ4SACKBGOtoCpTCIOzHTlV0YffmsUbrB9Yso xrtw2PEIJSWHRelUve0yCspNBJWSRq+rw2hZfGwGqVt0wr7u0ixY39P+xqw6Uo9/AqKk QBDvgmftQbylIlFDmDWmCr21fIBkdWcN4dL1Qj1P65UZURPHjiPGo6+ui5sMW9RIiRR5 h+1fSsLNwIlMsFETLHqWaInfUtONefjQ9CyV+fWILMfXkQ0gkNuyUNBsDaBWKnJv09Bf l3izif24UPuq5Vf1lY+/Zc9XS7WlSjdnawuK9gIl2C018Omxcqc8Vb7etP4eLvGgrT4u kPeg== X-Gm-Message-State: AOAM532u2m4DLbP0VGcqZH8ZUk/ep+0TJMGttE97e/i6wXlr+R/7b1xf Wdk2wA+fH8HsGlXVgiQMm9K0fVBOgfWV20hhDFIJqA== X-Google-Smtp-Source: ABdhPJx9a4zCIArGY0AChL3VirHVqPhBe7pN8gu5AEHQYHVY4tk0rNlBpawh/ceItzmdJPbN50LNUdkkWfb7nfVrl8k= X-Received: by 2002:a17:906:d930:: with SMTP id rn16mr66545999ejb.412.1609759980793; Mon, 04 Jan 2021 03:33:00 -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: <20210103173112.GR27507@tamriel.snowman.net> From: Dave Page Date: Mon, 4 Jan 2021 11:32:50 +0000 Message-ID: Subject: Re: [pgAdmin4][Patch] - RM 5457 - Kerberos Authentication - Phase 1 To: Stephen Frost Cc: Khushboo Vashi , pgadmin-hackers Content-Type: multipart/alternative; boundary="000000000000d4515e05b8117345" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --000000000000d4515e05b8117345 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, 3 Jan 2021 at 17:31, 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 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 > libpq / > > > > > 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 > 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 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... 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=E2=80=99t those cases CVE worthy? --=20 --=20 Dave Page https://pgsnake.blogspot.com EDB Postgres https://www.enterprisedb.com --000000000000d4515e05b8117345 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, 3 Jan 2021 at 17:31, Stephen Frost <sfrost@snowman.net> wrote:
Greetings,

* Dave Page (dpage@p= gadmin.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 Ke= rberos
> > authentication,
> > > > > using SPNEGO to forward kerberos tickets through a= browser which will
> > > > > bypass the login page entirely if the Kerberos Aut= hentication
> > 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 don= e on it.
> > > >
> > > > I notice that 'delegated_creds' is being set bu= t 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_gs= s is that the
> > > > delegated credentials are stored on the filesystem in a= temporary
> > > > directory and then an environment variable is set to si= gnal to libpq /
> > > > the Kerberos libraries that the delegated credentials c= an be found in
> > > > the temporary file.=C2=A0 I don't see any of that h= appening in this patch-
> > is
> > > > that already handled in some way?=C2=A0 If not, what= 9;s the plan for making
> > > > that work?=C2=A0 Also important is to make sure that th= is 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 w= e=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 Postg= reSQL
> > servers -
> > > I believe that is where we=E2=80=99ll need to handle delegat= ed credentials,
> > correct?
> >
> > Yes, though I sure hope there isn't a plan to release just &#= 39;phase 1'
> > since that would imply that the user is still sending their passw= ord to
> > pgAdmin in some form that pgAdmin then turns around and impersona= tes the
> > user, basically completely against how Kerberos auth should be wo= rking
> > in this kind of a intermediate service arrangement.
> >
> > In other words, if just 'phase 1' is released, it'd p= robably 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 et= c, 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= 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 is= n'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 kerberise= d 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 ser= ver using Kerberos, and then use a non-kerberised FDW.=C2=A0

Why aren=E2=80=99t those cases CVE wo= rthy?
--
--
Dave Page
https://pgsnake.blogspot.com

EDB Postgres
= https://www.enterprisedb.com --000000000000d4515e05b8117345--