On Tue, 30 Jul 2002, Lamar Owen wrote:
> On Tuesday 30 July 2002 07:46 pm, Curt Sampson wrote:
>
> > 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.
Yup. So once again, we're getting in to the loop "well, if you do
this, this other layer of security protects from some other thing
and blah blah blah."
Given the choice between doing something simple that eliminates one
possible avenue of security holes, or doing an extensive, error-prone
analysis, to try to prove that that avenue doesn't have any holes and is
not likely to have any in the future, which is going to be more secure?
> 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.
Well, if this is your approach to security, we're just going to
have to stop arguing here. The correct approach to security is not,
"leave this line of attack open, if we can't show how it could
fail" but "close off that line of attack even if we can't show how
it would fail." If you don't agree with that, you're in disagreement
with me and every Internet security expert out there.
> No. Failure to keep up with security updates is the number one cause of
> security breaches.
Bzzt!
cjs
--
Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're
alllight. --XTC