Обсуждение: Disable TRUST authentication by using ClientAuthentication_hook

=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= <fabrizio@timbira.com.br> writes:
> 2018-07-13 9:01 GMT-03:00 Guillaume Lelarge <guillaume@lelarge.info>:
>> 2018-07-13 13:57 GMT+02:00 <kpi6288@gmail.com>:
>>> I’d like to disable the TRUST authentication method for certain servers
>>> where modification of pg_hba.conf and restarting a service is fairly easy
>>> for a number of users.

>> I'm not sure this is such a good idea. You may need the trust
>> authentication method, for example if you forgot the superuser password.
>> Otherwise, there's good chance you might use the ClientAuthentication hook
>> to do what you want.

> If you're an server admin you can disable the extension (editing
> shared_pre_load_libraries GUC), change password and then enable the
> extension again...

Or more to the point: exactly what is the threat model here?  ISTM
that someone with enough privilege to alter pg_hba.conf can probably
suppress loading of an extension too, so that the security added by
this idea is not just questionable but completely illusory.

What would actually move the goalposts a bit is to build a modified
server which doesn't have the TRUST code path at all, so that there
is no question of installing an extension or not; then somebody who
wants to defeat the security needs to be able to replace the server
executable.  But you don't need any hook if you do that.

BTW, the usual way to get around I-forgot-the-superuser-password
is to start the server in single-user mode and use that to issue
an ALTER USER ... PASSWORD command.  As long as your patch doesn't
break single-user mode, you don't need any other escape hatch.

            regards, tom lane

> -----Ursprüngliche Nachricht-----
> Von: Tom Lane <tgl@sss.pgh.pa.us>
>
> > If you're an server admin you can disable the extension (editing
> > shared_pre_load_libraries GUC), change password and then enable the
> > extension again...

I am aware of this and all the other points.

> Or more to the point: exactly what is the threat model here?

It is similar like with your garage door: locking it with a simple 50 year-old-key is still better than just clamping
itwith a wedge. It is certainly not as good as enforcing the door and putting a modern and solid lock to it.  

> ISTM that
> someone with enough privilege to alter pg_hba.conf can probably suppress
> loading of an extension too, so that the security added by this idea is not just
> questionable but completely illusory.

This is a valid point of concern. However, settings in pg_hba.conf need to be documented to allow modification of IP
addressranges etc. A few people have access to this and it is likely that they look into the manuals and find
alternativesettings. Configuration of libraries is not clear to everyone.  

>
> What would actually move the goalposts a bit is to build a modified server
> which doesn't have the TRUST code path at all, so that there is no question of
> installing an extension or not; then somebody who wants to defeat the
> security needs to be able to replace the server executable.  But you don't
> need any hook if you do that.

That is true but I came across a discussion that for several reasons a proposal to add build-time options for
authenticationmethods was not implemented. I'm trying to avoid modification of the source code if I can. I agree that I
mayhave to build a modified server if I don't find a better solution.  

Regards Klaus