Neil,

* Neil Tiffin (ne...@neiltiffin.com) wrote:
> > On Feb 17, 2015, at 3:40 AM, Yeb Havinga <yebhavi...@gmail.com> wrote:
> > Auditing superuser access means auditing beyond the running database.
> > The superuser can dump a table, and pipe this data everywhere outside of
> > the auditing domain. I cannot begin to imagine the kind of security
> > restrictions you'd need to audit what happens with data after libpq has
> > produced the results. My best guess would be to incorporate some kind of
> > separation of duty mechanism; only allow certain superuser operations
> > with two people involved.
> 
> 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.

> The use case examples, that I am familiar with, are that procedural policies 
> control what the db superuser can do.  If the policy says that the db 
> superuser cannot dump a table and pipe this data someplace without being 
> supervised by a third party auditor (building on the above), then what you 
> want in the log is that the data was dumped by whom with a date and time.  
> Thats it.  Its up to policies, audit review, management, and third party 
> audit tools, to pick up the violation.  Auditing’s job is to keep a complete 
> report, not prevent.  Prevention is the role of security.

Agreed, policy is how to handle superuser-level access and auditing can
assist with that but without having an independent process (one which
the PG superuser can't control, which means it needs to be a different
OS-level user), it's not possible to guarantee that the audit is
complete when the superuser is involved.

        Thanks!

                Stephen

Attachment: signature.asc
Description: Digital signature

Reply via email to