On 2/17/15 12:07 PM, Stephen Frost wrote:
My views are from working with FDA validated environments, and I don’t really 
understand the above.  It is not db auditing’s job to stop or control the 
access to data or to log what happens to data outside of PostgreSQL.  To audit 
a db superuser is very simple, keep a log of everything a super user does and 
to write that log to a write append, no read filesystem or location.  Since the 
db superuser can do anything there is no value in configuring what to log.  
This should be an option that once set, cannot be changed without reinstalling 
the PostgreSQL binary.  The responsibility for auditing/controlling any binary 
replacement is the operating system’s, not PostgreSQL.  In this environment the 
db superuser will not have authorized root access for the os.
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.
--
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