Re: Disabling trust/ident authentication configure option

Hello,

I am the one who suggested the patch to Credativ, so let me explain my
reasoning.

It is clear that it is basically impossible to get perfect security but
this patch would help to solve one small but for our use case quite
dangerous issue. Changing the password to something simple is immediately
obvious as a security flaw for most people who may come across database
configurations, but for the TRUST mode you actually need to know some
background on why this is dangerous and when. Especially as it is well
documented it might seem legit to some people who are not that experienced
with postgres setup. I think this case is sufficiently generic to be
applicable to many others and to justify to at least provide the option to
work around it. Preventing such configuration errors is a usual topic in
most hardening guidelines and most commercial databases take steps to offer
more secure mechanisms to implement passwordless access or reset passwords.

Regarding passwords what you are saying is basically a "People can leave
their windows open anyways, so why bother installing door locks" kind of
argument. In my opinion the secure way to go would be to allow exactly one
defined way to access the DB without authentication / reset authentication
tokens and make this way easily recognizable / auditable. A nice addition
would be to be able to force password policies (e.g. using passwordcheck +
something like cracklib)...

So please consider to include this patch as it does not change the default
behavior but implement a simple way to comply with security policies and
actually increase security for some specific use cases.

BR,

Volker Aßmann

On Thu, Apr 30, 2015 at 2:00 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Thu, Apr 16, 2015 at 9:55 AM, Bernd Helmle <mailings(at)oopsware(dot)de>
> wrote:
> > PostgreSQL is deployed as part of a larger technical solution (e.g. a
> > Telecommunication system) and a field engineer has to install/upgrade
> this
> > solution. The engineer is a specialist in the Telco domain and has only
> > little knowledge of databases and especially PostgreSQL setup.
> >
> > We now want to provide these kinds of users with pre-hardened packages
> that
> > make it very hard to accidentally expose their database. For this purpose
> > the patch allows to optionally disable the "trust" and "ident"
> > authentication methods. Especially the "trust" mechanism is very critical
> > as it might actually provide useful functionality for our user. Think of
> an
> > engineer who has to do a night shift upgrade with a customer breathing
> down
> > his neck to get the system back online. Circumventing all these
> > authentication configuration issues by just enabling "trust" is very easy
> > and looks well supported and documented.
>
> But... the user could use password authentication with the password
> set to "x" and that would be insecure, too, yet not prevented by any
> of this. I think it's pretty hard to prevent someone who has
> filesystem-level access to the database server from configuring it
> insecurely.
>
> Of course, it's fine for people to make changes like this in their own
> copies of PostgreSQL, but I'm not in favor of incorporating those
> changes into core. I don't think there's enough general utility to
> this to justify that, and more to the point, I think different people
> will want different things. We haven't, for example, ever had a
> request for this specific thing before.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>