Re: How to revoke privileged from PostgreSQL's superuser

On Wed, Aug 15, 2018 at 01:13:10PM -0700, Evan Rempel wrote:
> On 08/15/2018 12:28 PM, Bruce Momjian wrote:
> >On Wed, Aug 15, 2018 at 09:05:51AM -0700, Evan Rempel wrote:
> >>At the end of the day someone has full access and control and can do anything without auditing database statements.
> >>
> >>For instance, as the root user on the server, I can do:
> >>
> >>- shutdown the server database
> >>- copy the entire DB filespace to my workstation
> >>- change the workstation config for no logging/auditing
> >>- start the workstation Database
> >>- make all the changes I want at the workstation.
> >>- stop the workstation database
> >>- copy all of the files back to the server
> >>- start the server Database.
> >>
> >>no logging of any kind and all of the data would be suspect.
> >Well, that is an intersting attack, and I don't think it requires root
> >--- all it requires is access to the Postgres data directory. Frankly,
> >I don't know if there is a way to prevent the Postgres superuser from
> >silently disabling logging because the _data_ is fully under the control
> >of the Postgres superuser.
> Which highlights a small design flaw.
>
> For security purposes many applications have moved the configuration files out of the data folder.
> PHP and MySQL are two that come to mind.
>
> The postgresql.conf and the pg_hba.conf should NOT be stored in the database data directory. These files
> should NOT be owned or editable by the postgres user (OS user that postmaster is running as).
> The result is that security options and configuration options (such as logging) could NOT be changed by
> the postgres OS account, and thus NOT be cvhanged by the postgres superuser database account.

Well, the configuration files can be configured to not be in the data
directory, but the superuser can override those locations on startup, so
they can effectively be placed anywhere. I don't think it would help to
hard-code a root-owned directory, e.g. /etc, in the server binary ---
they could just use a custom binary.

This also doesn't help the case where the superuser copies the data
directory to a server where he is root on, modifies the database, then
copies it back.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +