Re: Disabling trust/ident authentication configure option

On Wed, May 20, 2015 at 5:21 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

>
> Please don't be discouraged here. Contributing to the PostgreSQL
> community can be frustrating when you don't get what you want, and
> even though I have been a member of this community for about 7 years
> now and am a major contributor and committer, I still very often do
> not get what I want.
>
>
But please don't view that as a personal rejection. I stand by what I
> said: disallowing trust authentication in pg_hba.conf will not slow
> down an attacker who wants to create a backdoor. I believe that to be
> true, and I can tell you why, but regardless of anything I say, you
> can still believe it to be false. I'm OK with that, and I hope you're
> OK with me having a different belief. It doesn't mean that I don't
> want you to continue reading this mailing list or suggesting things;
> in fact, I hope you will. The fact that I (and others) don't like
> this particular idea doesn't mean we won't like your next one, or the
> one after that.
>
> If this discussing has come across as bruising, I apologize for that.
> One of the things that sometimes happens is that somebody submits a
> patch and it goes for a long time without receiving any meaningful
> feedback. Then eventually, sometimes after a lot of work has been put
> into it, it gets rejected. That's not fun. So another approach is
> for people to respond right away when somebody posts a patch that they
> think is a bad idea and say: hey, wait, let's not do this, I think
> it's a bad idea. But then you can have a situation (which I think may
> have happened in this case) where a contributor feels that other
> people are jumping all over them. That's not fun, either.
>
> I don't know the answer to this problem. I'm not the world's greatest
> diplomat, and tone is even harder to read over email than it is in
> person. But I can tell you that I'm not mad at you personally, and I
> didn't spend time replying to this email thread just to get rid of
> you. If it came across that way, I'm sorry.
>
>
Yes I guess discussing via mail always lends itself to misinterpretations,
and people tend to read the worst possible interpretation :) So I am not
offended and also did not intend to offend you in my reply.

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.

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)
* 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)
- 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)
* 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

My guess is the group who actually profit is relatively small, but the
group of people actively affected would also be relatively small. I have no
idea about actual usage so I am not qualified to judge here :)