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 1kzFgE-0000bu-90 for pgadmin-hackers@arkaria.postgresql.org; Tue, 12 Jan 2021 09:09:34 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kzFfh-0000FL-Bw for pgadmin-hackers@arkaria.postgresql.org; Tue, 12 Jan 2021 09:09:01 +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 1kzFfh-0000F6-27 for pgadmin-hackers@lists.postgresql.org; Tue, 12 Jan 2021 09:09:01 +0000 Received: from mail-ej1-x636.google.com ([2a00:1450:4864:20::636]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kzFfZ-0006Nx-2O for pgadmin-hackers@postgresql.org; Tue, 12 Jan 2021 09:08:59 +0000 Received: by mail-ej1-x636.google.com with SMTP id q22so2461097eja.2 for ; Tue, 12 Jan 2021 01:08:52 -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=0nWtZHH3GG72Jr7u3LVHMiYGE7yhgliBFY0ygY4M/Y4=; b=OgjxJEuwWoQ8e4PdLkHDqSkIj6R8z5gDcK1+z/GFupGentvwDP2Pj3xqSyr498dwF0 jestU+oNGfacWN1nxZ+9arK1eZjFy4qIaz80HX9s+rzjbPSFLaX/DNSu19EWlX8hlOLG TGZzoxLVBN5LJ9wNW/C0qde9sNM3YRdkdNxUty2tiXDK08DoLafrdbjb3198qZ5UM6ft t0uTdwxyD+5LFdyRcl4NpWC3NVP72pLkfjiJxTFhPV3JVc+5mTEk5ZcEMEdarWUvUPaG 6ZtAkhFLLzv1eTIib9k8OB28/12TxfDKhyUC32RU48PPYfF46sOvUsOcpvfQPSlUAyIm 8pZQ== 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=0nWtZHH3GG72Jr7u3LVHMiYGE7yhgliBFY0ygY4M/Y4=; b=RLkkOBnV7GRmx857uQFWeDBBv15JbP3v0MlaMfOqdz06kkJNntXjX0bHgDhW8J7aBF UF3Igkc0qFtmAxpz5Vvg7tXTH78w+lQ91q0801mhPJlyW2dmK61v4EHKJTRtilqN7pcz kNrMJKwFQ1rAT07QEdRHbc0ymfliXzqVHXu7iqDtKBjzNvE/FDSp/S+TUa80QUmsHCTR nJ7Q2QFuKRfI6uZlZ5uO692ytmAZMlKvgCaq7mbLm3iUoPNaMVyBi/mi+pC90CW4MGvI zA9D9JaCb/7HzTyMDCqgWmYnz0tMSJXikA1ptd1KImGHq7TqtoTdy+GH4Ezuu/BD3ooC iAlQ== X-Gm-Message-State: AOAM533xSjVuJ7VCb3fmV0UVN78rcIODgD/p5EPSNB5XmiKkPlWSI9VG TvG7JLEuvaZJ5czHaLe56JiA9CdUtHdseBrsCV/Sww== X-Google-Smtp-Source: ABdhPJxZmXmCjoVob39Bo/HnN33gRkOXQiIGSEJJ2z8UKFnL9wNTopDeYCpKXcEgAyWaUQPbFT9GL1GsR/g1RQP0Xe4= X-Received: by 2002:a17:906:b24c:: with SMTP id ce12mr2477972ejb.89.1610442530629; Tue, 12 Jan 2021 01:08:50 -0800 (PST) MIME-Version: 1.0 References: <20210102154130.GO27507@tamriel.snowman.net> <20210102155947.GQ27507@tamriel.snowman.net> <20210103173112.GR27507@tamriel.snowman.net> <20210111165011.GP27507@tamriel.snowman.net> <20210111174221.GQ27507@tamriel.snowman.net> In-Reply-To: <20210111174221.GQ27507@tamriel.snowman.net> From: Dave Page Date: Tue, 12 Jan 2021 09:08:39 +0000 Message-ID: Subject: Re: [pgAdmin4][Patch] - RM 5457 - Kerberos Authentication - Phase 1 To: Stephen Frost Cc: Magnus Hagander , Khushboo Vashi , pgadmin-hackers Content-Type: multipart/alternative; boundary="000000000000f8416905b8b05ece" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --000000000000f8416905b8b05ece Content-Type: text/plain; charset="UTF-8" Hi On Mon, Jan 11, 2021 at 5:42 PM Stephen Frost wrote: > > Accessing systems outside of the Kerberized environment is obviously a > different situation as you *can't* use the Kerberos credentials- and, > hopefully, everyone is using password managers and has a distinct and > different password for every service they do use outside of the > Kerberized environment. When you're talking about a set of systems > which live inside of the Kerberized environment, however, it's simply > not sensible to ask the user to provide their *domain-level* credentials > which an attacker could use to log in as that user to the entire domain > and have complete access over their account and that's exactly what is > likely to end up being the case here because the only way to set this up > would be Kerberos for pgAdmin and LDAP for PG- at least until delegated > credentials are implemented. > Which is no worse than the current situation - in fact it's arguably better because there's one less system that isn't Kerberised. Don't forget, you (as the system administrator) also have the choice of whether or not to use Kerberos. If you're not happy to have the pgAdmin authentication be kerberised whilst the database server access is not, then don't enable Kerberos until phase 2 is complete. > > > You basically seem to be saying that once a user logs into something > using > > Kerberos, *everything* else they login to from there must also be done > > using Kerberos - which clearly will not be the case in the vast majority > of > > deployments. > > Everything else they login to from there in the same Kerberized > environment absolutely should be done using Kerberos delegated > credentials. That's the point of Kerberos delegation. Are you modeling > this approach based on some existing system which accepts Kerberos > logins but then *doesn't* allow use of delegated credentials to log into > other Kerberized systems from there? Surely SSH works great with > delegated credentials, as does any website that uses mod_auth_kerb or > mod_auth_gss, or IIS.. > > I sure hope that the vast majority of deployments where pgAdmin is set > up with Kerberos will be using Kerberos for logging into PG with > delegated credentials, and further, that we will be *strongly* > encouraging that as otherwise you might as well use LDAP auth for all of > it and accept that any compromise of the web server or of PG will result > in complete compromise of any user's account who accesses the system. > I suspect that may not be the case, or at least most people will be working in mixed environments, e.g. Kerberos on their local network with non-Kerberised RDS servers for example. This is certainly something I've seen in the field many times. > > I don't understand all this push-back. > There are benefits for some users with phase one alone, so I don't see (and still don't) a need to hold it back. It also potentially allows us to get feedback on things that don't work as expected earlier, to minimise any re-work that might be required. Don't forget that pgAdmin releases monthly (except around EOY for obvious reasons), and incrementally releases and adds features, unlike PostgreSQL. > > The intent is to do the 'phase 2', right? And it hopefully will happen > in relatively short order, no? At least, I'd think it would make sense, > while people have developer environments set up and working with > Kerberos to go ahead and get that part done. All I'm saying is that the > 'phase 1' part really shouldn't be independently released, or if it is, > it should be *heavily* caveated that it is strongly discouraged for > people to run it in an environment where pgadmin and PG are in the same > Kerberized environment because it's not possible to set that up, with > just phase 1 done, in a manner which would avoid the pgadmin and PG > servers seeing the user's password. > Phase 2 is scheduled to be done immediately. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EDB: http://www.enterprisedb.com --000000000000f8416905b8b05ece Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

On Mon, Jan 11, 2021 at 5:42 PM Stephen Frost <<= a href=3D"mailto:sfrost@snowman.net">sfrost@snowman.net> wrote:
<= /div>

Accessing systems outside of the Kerberized environment is obviously a
different situation as you *can't* use the Kerberos credentials- and, hopefully, everyone is using password managers and has a distinct and
different password for every service they do use outside of the
Kerberized environment.=C2=A0 When you're talking about a set of system= s
which live inside of the Kerberized environment, however, it's simply not sensible to ask the user to provide their *domain-level* credentials which an attacker could use to log in as that user to the entire domain
and have complete access over their account and that's exactly what is<= br> likely to end up being the case here because the only way to set this up would be Kerberos for pgAdmin and LDAP for PG- at least until delegated
credentials are implemented.

Which is n= o worse than the current situation - in fact it's arguably better becau= se there's one less system that isn't Kerberised.

Don't forget, you (as the system administrator) also have the c= hoice of whether or not to use Kerberos. If you're not happy to have th= e pgAdmin authentication be kerberised=C2=A0whilst the database server acce= ss is not, then don't enable Kerberos until phase 2 is complete.
<= div>=C2=A0

> You basically seem to be saying that once a user logs into something u= sing
> Kerberos, *everything* else they login to from there must also be done=
> using Kerberos - which clearly will not be the case in the vast majori= ty of
> deployments.

Everything else they login to from there in the same Kerberized
environment absolutely should be done using Kerberos delegated
credentials.=C2=A0 That's the point of Kerberos delegation.=C2=A0 Are y= ou modeling
this approach based on some existing system which accepts Kerberos
logins but then *doesn't* allow use of delegated credentials to log int= o
other Kerberized systems from there?=C2=A0 Surely SSH works great with
delegated credentials, as does any website that uses mod_auth_kerb or
mod_auth_gss, or IIS..

I sure hope that the vast majority of deployments where pgAdmin is set
up with Kerberos will be using Kerberos for logging into PG with
delegated credentials, and further, that we will be *strongly*
encouraging that as otherwise you might as well use LDAP auth for all of it and accept that any compromise of the web server or of PG will result in complete compromise of any user's account who accesses the system.

I suspect that may not be the case, or a= t least most people will be working in mixed environments, e.g. Kerberos on= their local network with non-Kerberised=C2=A0RDS servers for example. This= is certainly something I've seen in the field many times.
= =C2=A0

I don't understand all this push-back.

<= div>There are benefits for some users with phase one alone, so I don't = see (and still don't) a need to hold it back. It also potentially allow= s us to get feedback on things that don't work as expected earlier, to = minimise any re-work that might be required. Don't forget that pgAdmin = releases monthly (except around EOY for obvious reasons), and incrementally= releases and adds features, unlike PostgreSQL.
=C2=A0

The intent is to do the 'phase 2', right?=C2=A0 And it hopefully wi= ll happen
in relatively short order, no?=C2=A0 At least, I'd think it would make = sense,
while people have developer environments set up and working with
Kerberos to go ahead and get that part done.=C2=A0 All I'm saying is th= at the
'phase 1' part really shouldn't be independently released, or i= f it is,
it should be *heavily* caveated that it is strongly discouraged for
people to run it in an environment where pgadmin and PG are in the same
Kerberized environment because it's not possible to set that up, with just phase 1 done, in a manner which would avoid the pgadmin and PG
servers seeing the user's password.

Phase 2 is scheduled to be done immediately.=C2=A0=C2=A0
<= br>
--
--000000000000f8416905b8b05ece--