Robert Haas <robertmhaas@gmail.com> writes:
> I definitely think there's a need for a user who can manipulate
> objects in the database much like a superuser (i.e. access all
> objects, grant and revoke all privileges, etc.) but who can't break
> out into the OS user account and assume it's privileges. I'm not sure
> whether it's best to try to get there by creating a mode where the
> superuser's privileges are trimmed back, or to get there by still
> having a super-user who is just as super as at present but then also
> have the ability to create other users who are not superusers but have
> many of the same privileges with respect to in-database objects.
Maybe I shouldn't be putting words into Nathan's mouth, but I think
what he is after is a mode intended for use by cloud service providers,
who would like to offer locked-down database services where there's
just no way to get to the disk from inside the DB, superuser or no.
What you're talking about is perhaps interesting to a different set of
people, but it doesn't offer any guarantees because it's always possible
that $attacker manages to hack his way into access to a superuser role.
> It seems to me that you've got to think not only about vectors for
> executing arbitrary C code and/or shell commands, but also the
> superuser's power to mess with the catalogs. If you can UPDATE
> pg_proc, you can certainly hack the system, I think.
I think if all the functions that would let you get to the disk are
disabled at the C-code level, it doesn't much matter what the catalogs
say about them.
The main flaw I'm aware of in that argument is that it used to be possible
for superusers to create C-language pg_proc entries pointing at random C
entry point symbols, eg open(2) or write(2), and then invoke those
functions from SQL --- maybe with only restricted possibilities for the
arguments, but you just need to find one combination that works.
When we got rid of v0 function call support, that became at least far
more difficult to exploit, but I'm not sure if it's entirely impossible.
A component of this exercise would need to be making sure that that's
bulletproof, ie you can't make a usable pg_proc entry that points at
something that wasn't meant to be a SQL-callable function.
> In my mind, it's
> reasonable as a matter of security policy to decide that you don't
> ever want plperlu on your system, only plperl.
Absolutely, but for that you can just not install plperlu's extension
support files.
If you're concerned about whether that decision is un-hackable, then
you soon realize that you need a bulletproof no-disk-access restriction.
regards, tom lane