Re: Disabling trust/ident authentication configure option

On Mon, May 18, 2015 at 5:58 AM, Josh Berkus <josh(at)agliodbs(dot)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