Re: For review: Server instrumentation patch

"Magnus Hagander" <mha(at)sollentuna(dot)net> writes:
>> Yeah. It's worth pointing out in this connection that
>> server-side COPY is already pretty well crippled if you are
>> running under SELinux, because the security policy constrains
>> what parts of the filesystem the daemon can reach at all.

> I don't know a lot about SELinux, but wouldn't this give the exact same
> level of security for the new admin functions in this case?

It would prevent them from reaching unwanted parts of the filesystem,
yes, but that has little to do with the privilege-escalation problem.

I see I had better spell out the reasoning here. Assume that a bad guy
has gotten hold of your database superuser password and is now trying
to parlay that into shell-level access to the underlying system (which
is to say, the ability to execute shell commands of his choice; whether
he ever acquires a login password is secondary). If you've installed an
utrusted PL then the game is over immediately, so let's assume you
didn't. One way that the attacker might proceed is to try to make a .so
file that he can LOAD into the backend containing the equivalent of a
system() function. I believe this is not feasible using COPY in its
current form, mainly because you can't write arbitrary binary files with
it (no embedded zeroes for instance). With a function to write
arbitrary file contents, one very large stumbling block goes away.
There's still a problem of getting the file to have the right executable
permission bits, but that might be surmounted in various ways, for
instance by finding an existing program or .so file that the backend has
permission to overwrite. (Somebody argued yesterday that the attacker
could always build such a file by executing a shell script, but that
misses the point: we are considering how the attacker can get to the
point of being able to issue shell commands, not what he can do once
he's got that.)

So it seems clear to me that adding a file-write function adds a very
substantial amount of risk from a privilege-escalation point of view.
Yes, it's only one link in a chain, but it's a big link.

> Let me suggest another nice way for a superuser to do whatever he wants.
> How about "CREATE UNTRUSTED PROCEDURAL LANGUAGE"? If you have say
> pl/perl or pl/tcl on the system, you just create the untrusted version
> and away you go - because they use the same .so.

Yeah, I was thinking earlier about proposing that the trusted and
untrusted versions need to be distinct .so's, so that the admin can
physically remove the untrusted ones to prevent this scenario.
But, again, the existence of security hole A is not justification for
introducing security hole B.

> Instead of trying to pick on one feature, how about trying something
> constructive instead?

That'd be fine with me --- but we have to introduce that *before* we add
obvious new security risks, not after.

regards, tom lane