I've been giving a lot of thought to some of the questions raised
by my SSL patch, and have both a conclusion and a really stupid
question.

First, the conclusion is that what I'm working on is "secure sessions."
As I mentioned before, that's not just encryption (e.g., SSH tunnels),
but the combination of confidentiality (encryption), message integrity
and endpoint authentication.  This is what people think you mean when
you say an application "supports" Kerberos or SSL, and it's what's
required for really sensitive information.

(E.g., nobody cares that the data was encrypted if the confidential
information supporting a search warrant went to the bad guys instead
of directly to the central police database.  The snitch is still
dead, and the evidence destroyed.)

The latest SSL patches will be out by this weekend, and I hope to
add GSS-API (which includes Kerberos 5) soon afterwards.  Both will
publish their endpoint authentication information (X509 structure
and strings containing subject and issuer distinguished names, string
containing Kerberos principal name), and the HBA code can then use
this information for PostgreSQL authentication.

...

The really stupid question refers to some of the hardcoded fallback
values in this code.  The reason for having hardcoded values is to
prevent "downgrade" attacks - you don't want to casually override the
DBA, but you also don't want to make it easy for a knowledgeable
attacker to fatally compromise the system in a way that your average
DBA couldn't catch.

But the problem is that knowledgeable security administrators can
replace the common hardcoded values with their own.  How do you allow
this to be easily done?

One possibility that occured to me was that dynamic libraries would
handle this nicely.  There's even some support for dynamic libraries
in the user-defined functions, so this wouldn't be a totally
unprecedented idea.

But this would be a new way of using dynamic libraries.  Is this
something everyone is comfortable with, or is it problematic for
some reason?  Or is this premature - maybe the first release should
just use hardcoded values with a note to contact individuals if
there's an interest in a dynamic library approach?

Bear

Thu, 23 May 2002 11:48:54 -0600 (MDT)
Bear Giles <bgiles@coyotesong.com>
Really stupid question(?)
Bear Giles <bgiles@coyotesong.com> writes:
> But the problem is that knowledgeable security administrators can
> replace the common hardcoded values with their own.  How do you allow
> this to be easily done?

Configuration parameters?

> One possibility that occured to me was that dynamic libraries would
> handle this nicely.  There's even some support for dynamic libraries
> in the user-defined functions, so this wouldn't be a totally
> unprecedented idea.
> But this would be a new way of using dynamic libraries.

You've lost me completely.  What exactly are you suggesting?

			regards, tom lane

Thu, 23 May 2002 16:10:39 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Really stupid question(?) 
Bear Giles wrote:
> The really stupid question refers to some of the hardcoded fallback
> values in this code.  The reason for having hardcoded values is to
> prevent "downgrade" attacks - you don't want to casually override the
> DBA, but you also don't want to make it easy for a knowledgeable
> attacker to fatally compromise the system in a way that your average
> DBA couldn't catch.
> 
> But the problem is that knowledgeable security administrators can
> replace the common hardcoded values with their own.  How do you allow
> this to be easily done?

Would GUC variables work? Put in sensible defaults and let the more 
knowledgeable security admins override the defaults in postgresql.conf

Joe




Thu, 23 May 2002 13:29:47 -0700
Joe Conway <mail@joeconway.com>
Re: Really stupid question(?)