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.
Ideally the audit logging and statement logging should NOT be permitted to be controlled via session
commands (i.e. the client)
Just my $0.02
--
Evan
