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

* Jim Nasby (Jim.Nasby@BlueTreble.com) wrote:
> On 2/17/15 12:50 PM, Stephen Frost wrote:
> >* Jim Nasby (Jim.Nasby@BlueTreble.com) wrote:
> >>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.
> >
> >That's an interesting thought but it doesn't seem too likely to work out
> >for us.  The process still has to be able to read and write the files,
> >create new files in the PGDATA directories, etc.
>
> Right, but if we don't allow things like loading C functions from
> wherever you please then it's a lot less likely that a DB SU could
> disable auditing.

It's not just C functions, there's also a whole slew of untrusted
languages, and a superuser can modify the catalog directly.  They could
change the relfileno for a relation to some other relation that they're
really interested in, or use pageinspect, etc.

> >>Or maybe there's some other way we could restrict what a DB
> >>superuser can do in the shell.
> >
> >This could be done with SELinux and similar tools, but at the end of the
> >day the answer, in my view really, is to have fewer superusers and for
> >those superusers to be understood to have OS-level shell access.  We
> >don't want to deal with all of the security implications of trying to
> >provide a "trusted" superuser when that user can create functions in
> >untrusted languages, modify the catalog directly, etc, it really just
> >doesn't make sense.
>
> The part I don't like about that is then you still have this highly
> trusted account that can also run SQL. The big issue with that is
> that no OS-level auditing is going to catch what happens inside the
> database itself (well, I guess short of a key logger...)

Right- you would need an independent process which acts as an
intermediary between the database and the account connecting which
simply logs everything.  That's really not all *that* hard to do, but
it's clearly outside of the scope of PG.

> What I'd prefer to see is a way to decouple the OS account from any
> DB account. Clearly that doesn't protect us from the OS user doing
> something bad, but at least then there's no way for them to just
> silently run SQL commands.

If the DB account isn't a superuser then everything changes.  There's no
point fighting with the OS user- they can run some other PG binary which
they've copied over locally and run SQL with that, or copy all the files
over to another server which they have complete access to.  The fact
that they can also connect to the DB and run SQL isn't really an issue.
Thanks,
    Stephen