Re: Bugtraq: Having Fun With PostgreSQL

"Andrew Hammond" <andrew(dot)george(dot)hammond(at)gmail(dot)com> writes:
> On 6/25/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> +1 on having such a discussion in the manual (someone else suggested
>> that already IIRC). But I'm not seeing what a configure flag brings
>> to the party.

> Like Andrew Sullivan said above, if we want to achieve the dubious
> goal of being "secure by default" this seems like the least invasive
> way to change the process so that we can be buzzword compliant.

It still wouldn't make us "secure by default". Not unless you propose
to actually change the default.

In any case, what is "secure by default"? The current default
configuration is entirely secure against outside attacks, because it
doesn't even allow outside connections. As for inside connections,
"secure" is still largely dependent on what your threat model is.
The paper that started this whole thread pointed out that "ident" auth
can expose you to problems even over a Unix socket, given the right set
of conditions. Shall we reject "ident" as not being sufficiently
secure? Better get rid of Kerberos, too, since that depends on an
outside server that could be compromised. And MD5 is certainly not good
enough, since PG doesn't force you to change to a new 12-character
not-in-the-dictionary password every week. Any of these things could be
considered to be not secure enough, depending on the user's situation.

I'm all for providing a more thorough discussion of these matters in
the manual. I'm not for changing the default behavior, nor for throwing
another roadblock into a day-zero newbie's experience with Postgres.
Ultimately it's the user's responsibility to determine what is
adequately secure for him.

regards, tom lane