On 2/17/15 12:23 PM, Stephen Frost wrote:
* Jim Nasby (jim.na...@bluetreble.com) wrote:
On 2/17/15 12:07 PM, Stephen Frost wrote:
I agree that it's not the auditing job to stop or control access to
data, but it's not so simple to audit the superuser completely.  The
issue is that even if you have a hard-coded bit in the binary which says
"audit everything", a superuser can change the running code to twiddle
that bit off, redirect the output of whatever auditing is happening,
gain OS-level (eg: shell) access to the system and then make changes to
the files under PG directly, etc.  Setting a bit in a binary and then
not allowing that binary to be unchanged does not actually solve the
issue.

If we've allowed a superuser *in the database* that kind of power at
the OS level then we have a problem. There needs to be *something*
that a database SU can't do at the OS level, otherwise we'll never
be able to audit database SU activity.

This isn't a question.  The database superuser has essentially OS-level
privileges as the user which PG runs as.

I'm all for coming up with a less powerful superuser and the work I've
been involved in around adding more role attributes is along the lines
to get us there, but I don't think we're ever going to really reduce the
power that the PG superuser has, for a variety of reasons.

Improving the documentation of what a superuser can do and how granting
such access is the same as giving OS shell-level access to the system as
the user that PG runs as would certainly be good.

It certainly would. I'm honestly not totally clear on what all the holes are.

We may need to bite the bullet and allow changing the user that the postgres process runs under so it doesn't match who owns the files. Maybe there's a way to allow that other than having the process start as root.

Or maybe there's some other way we could restrict what a DB superuser can do in the shell.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to