Re: Disabling trust/ident authentication configure option

Поиск
Список
Период
Сортировка
От Volker Aßmann
Тема Re: Disabling trust/ident authentication configure option
Дата
Msg-id CAJBpAdzUeVqJ1R+0V_Eg8+Z0HdrHYq7HHx+a4q1BT9-h9Yvoiw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Disabling trust/ident authentication configure option  (Josh Berkus <josh@agliodbs.com>)
Ответы Re: Disabling trust/ident authentication configure option  (Bruce Momjian <bruce@momjian.us>)
Re: Disabling trust/ident authentication configure option  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Mon, May 18, 2015 at 5:58 AM, Josh Berkus <josh@agliodbs.com> wrote:
 
Let's say we offered a compile-time option, and then someone built a
package postgresql-9.6-secureauth.deb.  So, your lazy admin is having
trouble debugging an auth problem and wants to set "trust".  But they
can't.  So they search on Google and figure out how to download and
install postgresql-9.6-normalauth.deb.  Or, alternately, they set all
passwords to "password" or to "".  Or they put .pgpass files on all
machines.  Or they put the password in pgbouncer and set pgbouncer to
"trust".


We have a specific use case were servers don't connected directly to the internet (package replacement is hard) and the client application manages credentials in a reasonably secure fashion. Of course these measures are rendered moot if some careless admin can just set authentication to "trust" for a quick upgrade and forgets about this.

I know these measures won't protect against an experienced attacker who gains root access, but hope it slows them down sufficiently so the admins may have a chance to detect the attack.
 
Now, if you wanted to add an audit log every time someone changes an
auth method in pg_hba.conf?  I'd be all for that, I can see all kinds of
uses for that, and it might actually accomplish something effective.

This would also be a valuable security measure to implement.
 
If you disagree with me, well, it would be very easy to hack out the
auth methods you don't like and compile your own.  It *is* open source.

 
That's what we are currently doing with the patch Bernd posted at the beginning of this thread. But we thought we might post the patch for consideration here as the use case might be sufficiently general that it may be of use to others.

But I like the more general approach proposed by Alvaro, so in case this patch would have a chance to not be immediately rejected, I would try to implement the more generic approach. I would also include a check to ensure at least one reasonably secure way for password recovery is available. For Unix systems "peer" authentication seems to be a good candidate.

Best regards,

    Volker

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

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: Disabling trust/ident authentication configure option
Следующее
От: Tom Lane
Дата:
Сообщение: Re: upper planner path-ification