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 <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
