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

Поиск
Список
Период
Сортировка
От Dave Page
Тема Re: [pgAdmin4][Patch] - RM 5457 - Kerberos Authentication - Phase 1
Дата
Msg-id CA+OCxozRocruLjk=Mvh7sUzp9tkx9cvOFLdYvu3nEGriW0QEzg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [pgAdmin4][Patch] - RM 5457 - Kerberos Authentication - Phase 1  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: [pgAdmin4][Patch] - RM 5457 - Kerberos Authentication - Phase 1  (Magnus Hagander <magnus@hagander.net>)
Список pgadmin-hackers
Hi

On Mon, Jan 11, 2021 at 5:42 PM Stephen Frost <sfrost@snowman.net> 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

В списке pgadmin-hackers по дате отправления:

Предыдущее
От: Dave Page
Дата:
Сообщение: Re: Somewhat excessive version checks
Следующее
От: Akshay Joshi
Дата:
Сообщение: Re: [pgAdmin][RM5488] Tooltip information does not display properly if user check all options under explain analyze