Re: WAL file location

On Tuesday 30 July 2002 07:46 pm, Curt Sampson wrote:
> On Tue, 30 Jul 2002, Lamar Owen wrote:
> > I said it. In any case, using strings that are in the environment
> > requires an untrusted PL, or a C function.

> Ah. See, we already have a failure in a security analysis here. This
> command:

>     CREATE DATABASE foo WITH LOCATION = 'BAR'

> uses a string that's in the environment.

And requires you to be a database superuser anyway.  You got something better? 
:-)  If you're the database superuser, you can do anything you want inside 
the database.  Your analysis here is faulty.

> So what you're saying is that we should make the opportunity for people
> to configure the system in an insecure manner?

No, what I'm saying is that there is no such thing as absolute security -- and 
time is better spent where there is a measureable result.  If a security hole 
requires root to exploit, then it's not a hole.  Show me a case where an 
envvar can be exploited by an unprivileged database user without accessing a 
user written C function or some other function in an untrusted PL.

> Configuration errors by administrators are probably the number one
> cause of security breaches, you know.

No.  Failure to keep up with security updates is the number one cause of 
security breaches.  I guess you could call that a configuration problem of 
sorts.  Been there; done that.  Experienced one hack in -- caught it in the 
act.  But I _have_ been there, and I have had to clean up other people's 
configuration errors.

> I've been securing systems since I started an ISP in 1995, and so I've
> seen a lot of security vulnerabilities come and go, and I've got a bit
> of a feel for what kinds of things are typically exploited. And this one
> one just screams, "potential security vulnerability!" to me.

But, just like any other vulnerability, an admin must ask the question 'is a 
successful exploit a problem?'  Again, if an exploit requires root to 
activate, then it's not a problem in reality.  If I have to be the database 
superuser to activate an ennvar exploit in postgresql, then it's not a 
vulnerability, as I have more powerful tools at my disposal as superuser.  
Things such as DROP DATABASE.

Now if a normal user can easily exploit it remotely (like the two in a row for 
OpenBSD in the past month), then it's an issue.  A big issue.

You just have to keep perspective.  And I'm not going to put myself as any 
authority on the subject, but I do have a couple of years in the trenches, 
having admined systems for over 15 years.  I've been at it long enough to 
realize that I am most certainly fallible.
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11