Re: Disabling trust/ident authentication configure option

Volker,

> I likely just viewed this too much through a "security" lens - you see a
> possible attack scenario, a way to turn it off, and only minor
> downsides, so just go for it - but this is not how you can work in a
> huge open source project. I guess as a developer you would have to take
> many other issues (like maintainability, user confusion because of the
> change, edge use cases) into account. And as it seems to cause too much
> trouble for "official inclusion" I am fine with patching it during our
> package build.

The security issue you're trying to address is real.  My argument is
that you're addressing it in the wrong way.

So from my perspective anything which requires going off standard
PostgreSQL packages, and encourages users to go off standard PostgreSQL
packages, is a actually a fairly high cost even if the code is
non-invasive.  I would be more open to a GUC which limited the auth
mechansisms available (requiring restart to change), for example, than a
compile flag.

> And yes once someone has write access to your pg_hba.conf you are very
> likely doomed. This would just prevent an attack happening through a
> careless "trust" entry left there, which is just a very quick win for an
> attacker, and may be a bit less likely through this patch.
> 
> 
> To answer to Tom: I see a restricted audience for this patch, but also
> no impact for anyone not wanting to use it. The group of users I see
> would be as follows:
> 
> * People who package PostgreSQL as part of their product and want to
> provide their customers with a restricted "more secure" functionality
> set only to reduce training and support effort. (my use case)

Doesn't it may more sense to deny them direct access to pg_hba.conf
entirely?  I don't understand the use-case here, I guess.

> * People with large Postgres deployments who build their own packages
> and want to enforce a certain security policy (e.g. services are not
> allowed to offer authentication-less access over the network)

It's hard for me to see this argument as persuasive because anyone with
a large deployment is going to be using configuration management, and
CMS already can be configured to control pg_hba.conf, far more
effectively than merely denying specific auth methods.

>    - specifically a good security plan would be to only allow a "safe
> subset" of methods and ensure that these are well documented and perhaps
> audited automatically
>    - this would also allow ensuring there is only one documented /
> audited way to reset passwords (modulo single user mode, that is an
> additional problem which won't be easily fixable)

This latter (forcing users to only use GSSAPI auth, for example) would
be something which would be nice to support, athough again CMS.

> * Distributions which want to provide a more secure package and want to
> ensure each available method can be configured securely and documented
> clearly for their specific setup.
> 
> It does not apply to (or would have a negative effect for) the following
> groups:
> 
> * PostgreSQL users on Windows (disabling trust should not work or should
> show a very prominent warning)
> * Users of default builds (they simply won't be affected)
> * People with a specific use case requiring "trust", "ident" or for the
> more generic patch other specific auth methods. They will be affected if
> they happen to be using a build with this method turned off.
> * People who are used to resetting passwords using "trust" and are
> surprised this suddenly does not work on some specific system

The above is a good list of reasons why we can't realistically remove
Trust from the codebase entirely.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com