Privilege boundary between sysadmin and database superuser [Was: Re: pg_amcheck option to install extension] - Mailing list pgsql-hackers

> On Apr 20, 2021, at 5:54 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Tue, Apr 20, 2021 at 1:31 AM Mark Dilger
> <mark.dilger@enterprisedb.com> wrote:
>> I think you are conflating the concept of an operating system adminstrator with the concept of the database
superuser/owner.
>
> You should conflate those things, because there's no meaningful
> privilege boundary between them:

I understand why you say so, but I think the situation is more nuanced than that.

> http://rhaas.blogspot.com/2020/12/cve-2019-9193.html
>
> If reading the whole thing is too much, scroll down to the part in
> fixed-width font and behold me trivially compromising the OS account
> using plperlu.

I think the question here is whether PostgreSQL is inherently insecure, meaning that it cannot function unless
installedin a way that would allow the database superuser Bob to compromise the OS administered by Alice. 

Magnus seems to object even to this formulation in his blog post,
https://blog.hagander.net/when-a-vulnerability-is-not-a-vulnerability-244/,saying "a common setup is to only allow the
postgresOS user itself to act as superuser, in which case there is no escalation at all."  He seems to view Bob taking
overthe OS account as nothing more than Alice taking over her own account, since nobody but Alice should ever be able
tolog in as Bob.  At a minimum, I think that means that Alice must trust PostgreSQL to contain zero exploits.  If
databaseuser Charlie can escalate his privileges to the level of Bob, then Alice has a big problem.  Assuming Alice is
anaverage prudent system administrator, she doesn't really want to trust that PostgreSQL is completely exploit free.
Shejust wants to quarantine it enough that she can sleep at night. 

I think we have made the situation for Alice a bit difficult.  She needs to make sure that whichever user the backend
runsas does not have permission to access anything beyond the PGDATA directory and a handful of postgres binaries,
otherwiseBob, and perhaps Charlie, can access them.  She can do this most easily with containers, or at least it seems
soto me.  The only binaries that should be executable from within the container are "postgres", "locale", and whichever
hardenedarchive command, recovery command, and restore command Alice wants to allow.  The only shell that should be
executablefrom within the container should be minimal, maybe something custom written by Alice that only works to
recognizethe very limited set of commands Alice wants to allow and then forks/execs those commands without allowing any
furthershell magic.  "Copy to program" and "copy from program" internally call popen, which calls the shell, and if
Alice'scustom shell doesn't offer to pipe anything to the target program, Bob can't really do anything that way.
"locale-a" doesn't seem particularly vulnerable to being fed garbage, and in any event, Alice's custom shell doesn't
haveto implement the pipe stream logic in that direction.  She could make it unidirectional from `locale -a` back to
postgres. The archive, recovery, and restore commands are internally invoked using system() which calls those commands
indirectlyusing Alice's shell.  Once again, she could write the shell to not pipe anything in either direction, which
prettywell prevents Bob from doing anything malicious with them. 

Reading and writing postgresql data files seems a much trickier problem.  The "copy to file" and "copy from file"
implementationsdon't go through the shell, and Alice can't deny the database reading or writing the data directory, so
theredoesn't seem to be any quarantine trick that will work.  Bob can copy arbitrary malicious content to or from that
directory. I don't see how this gets Bob any closer to compromising the OS account, though.  All Bob is doing is
messingup his own database.  Even if corrupting these files convinces the postgres backend to attempt to write
somewhereelse in the system, the container should be sufficient to prevent it from actually succeeding outside its own
datadirectory. 

The issue of the pg_read_file() sql function, and similar functions, would seem to fall into the same category as "copy
tofile" and "copy from file".  Bob can read and write his own data directory, but not anything else, assuming Alice set
upthe container properly. 

> I actually think this is a design error on our part. A lot of people,
> apparently including you, feel that there should be a privilege
> boundary between the PostgreSQL superuser and the OS user, or want
> such a boundary to exist.

I'm arguing that the boundary does currently (almost) exist, but is violated by default, easy to further violate
withoutrealizing you are doing so, inconvenient and hard to maintain in practice, requires segregating the database
superuserfrom whichever adminstrator(s) execute other tools, requires being paranoid when running such tools against
thedatabase because any content found therein could have been maliciously corrupted by the database administrator in a
waythat you are not expecting, requires a container or chroot jail and a custom shell, and this whole mess should not
bemade any more difficult. 

We could make this incrementally easier by finding individual problems which have solutions generally acceptable to the
communityand tackling them one at a time.  I don't see there will be terribly many such solutions, though, if the
communitysees no value in putting a boundary between Bob and Alice. 

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company