Re: pgaudit - an auditing extension for PostgreSQL

On 2/17/15 12:23 PM, Stephen Frost wrote:
> * Jim Nasby (Jim(dot)Nasby(at)BlueTreble(dot)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