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
> 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
> 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.
WGCR Internet Radio
1 Peter 4:11
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2002-07-31 03:29:12|
|Subject: Re: getpid() function |
|Previous:||From: Bruce Momjian||Date: 2002-07-31 03:15:33|
|Subject: Re: Why is MySQL more chosen over PostgreSQL?|