Re: pgaudit - an auditing extension for PostgreSQL - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: pgaudit - an auditing extension for PostgreSQL
Date
Msg-id 54E38A88.5030607@BlueTreble.com
Whole thread Raw
In response to Re: pgaudit - an auditing extension for PostgreSQL  (Stephen Frost <sfrost@snowman.net>)
Responses Re: pgaudit - an auditing extension for PostgreSQL  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On 2/17/15 12:23 PM, Stephen Frost wrote:
> * Jim Nasby (Jim.Nasby@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



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: pgaudit - an auditing extension for PostgreSQL
Next
From: Stephen Frost
Date:
Subject: Re: pgaudit - an auditing extension for PostgreSQL