* Neil Tiffin (neilt@neiltiffin.com) wrote:
> On May 4, 2014, at 5:27 PM, Stephen Frost <sfrost@snowman.net> wrote:
> > * Neil Tiffin (neilt@neiltiffin.com) wrote:
> > Well, except that a superuser *could* effectively turn off checksums by
> > changing the the control file and doing a restart (perhaps modulo some
> > other hacking; I've not tried). That kind of trivial 'hole' isn't
> > acceptable from a security standpoint though and given that we couldn't
> > prevent a superuser from doing an LD_PRELOAD and overriding any system
> > call we make from the backend, it's kind of hard to see how we could
> > plug such a hole.
> >
>
> Ah, I thought it would be more difficult than that for checksums, but PostgreSQL does not have to prevent hacking in
myexperience, that is the responsibility of other systems and procedures. If the core code was such that once on,
formallogging could not be turned off with any changes to config files, settings, or SQL then in my experience that
wouldsuffice.
We could set it up similar to how security labels work, where the
config file (which could be owned by 'root' and therefore unable to be
changed by a superuser) has an auditing setting and changing it requires
a restart (meaning that the config file would have to be modified to
change it, and the database restarted). However, it might be possible
for a superuser to configure and start an independent postmaster with a
different configuration that points to the same database (or a copy of
it).
That's for a system-wide auditing setting, but if we actually want the
auditing to only be on certain database objects, it gets worse. We
need to track what objects need the auditing and we'd do that using the
catalog, which a superuser can modify. Security labels have
more-or-less the same issue, of course.
This is why we don't try to protect against superusers (and why I'm
hopeful that we can reduce the need for a superuser role to exist).
Again, we have to consider that a superuser essentially has a full shell
on the DB server as the user that the database runs under.
Thanks,
Stephen