On Tuesday 30 July 2002 02:34 pm, Tom Lane wrote: > Andrew Sullivan <[EMAIL PROTECTED]> writes: > > On Tue, Jul 30, 2002 at 02:05:57PM -0400, Tom Lane wrote: > >> If we add more environment-variable-dependent mechanisms to allow more > >> different things to be done, we increase substantially the odds of > >> creating an exploitable security hole.
> > Ok, true enough, but I'm not sure that a config file or any other > > such mechanism is any safer. As Lamar Owen said, anyone who can > > poison the postgres user's environment can likely do evil things to > > postgresql.conf as well. > Who said anything about poisoning the environment? My point was that > there will be strings in the environment that were put there perfectly > legitimately, but could still serve as an attack vehicle. I said it. In any case, using strings that are in the environment requires an untrusted PL, or a C function. Regardless, if such a hole was exploited the only security risk to the system at large is that posed by the postgres user, which, IMHO, shouldn't even have write access to its own executables. And if someone can exploit the environment in that way, with a server-side function, then that same person will be able to execute arbitrary code as the postmaster run user anyway, without any environment variables being accessed. Unless environment access is allowed in trusted functions.... Although that is one reason the HOME for the RPMset is /var/lib/pgsql, a place postgres has free rein anyway. > The weakness of the existing database-locations-are-environment-variables > feature is really that the attacker gets to choose which environment > variable gets used, and so he can use a variable intended to serve > purpose A for some other purpose B. If A and B are sufficiently > different then you got trouble --- and since we are talking about a > purpose B that involves writing on something, there's definitely a risk. To data already owned by postgres only. I wouldn't mind seeing an example of such an exploit, for educational purposes. Having said all that, I still believe that this is something tailor-made for postgresql.conf. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
