Re: For review: Server instrumentation patch

> > It could be argued that there should be provision for a
> limitation on
> > the locations in which COPY can write (and maybe read) files.
> > If COPY is a security hole then we should close it, not use that as
> > precedent to open another hole.
>
> 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?

> Nonetheless, the patch makes it vastly easier for an attacker to do
bad things, and vastly harder for an >
> admin to try to lock down the database adequately. For instance, the
question of .so security can be
> attacked by not installing any .so's that you don't want used;
likewise a contrib file-access module can
> be left off the system if it's considered a hazard. But if the
functionality is part of the core database
> then it's exceedingly difficult for someone who doesn't want it to get
rid of it.
>
> (I believe that you'd actually have to recompile the server with the
dangerous functions removed; just
> deleting their pg_proc entries doesn't stop someone from recreating
those entries.)

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. This lets you not only
modify files on the system, but execute arbitrary code on the system.
If you want to protect the system from a hacked superuser, you will have
to remove the concept of untrusted procedural languages as well.
Oh, and probably LOAD; since the superuser can LOAD any .so on the
system IIRC - including stuf that a local user may stuff in /tmp/ or
wherever.

> Saying "we don't need to lock this down because there are other
possible attacks" is about like leaving
> your front door open because you know that a determined burglar could
get in by breaking a window. You
> may or may not want to install steel bars over the windows, but that's
no argument for leaving the door open.

I would rather equal it with "we don't lock the door, because the door
1m to the left of it is open anyway". You don't need to break anything
to get in either way.

Instead of trying to pick on one feature, how about trying something
constructive instead? Let's say we add a GUC like "restrict_superuser",
that disables COPY to local files, untrusted procedural languages (both
creation and using the ones that already exist), the new access
functions, the LOAD command etc. Then the admin can chose what to do
about superuser access levels - the requirement may dependon SELinux for
example.

next mail:
> Given that COPY to/from a file is already allowed only to superusers,
I'm not sure how effective a GUC
> variable will be in constraining what they do with it. We'd have to
at least restrict it to SIGHUP,
> which'd mean you couldn't change it without the ability to write the
config file.

You are kidding, right? Your original argument here was that "restricted
to superuser is not security for the new functions", how can restricted
to superusers be security for COPY?!

//Magnus