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