The audit information produced by PostgreSQL must be protected from unauthorized deletion.

From PostgreSQL 9.x Security Technical Implementation Guide

Part of SRG-APP-000120-DB-000061

Associated with: CCI-000164

SV-87537r2_rule The audit information produced by PostgreSQL must be protected from unauthorized deletion.

Vulnerability discussion

If audit data were to become compromised, then competent forensic analysis and discovery of the true source of potentially malicious system activity is impossible to achieve.To ensure the veracity of audit data, the information system and/or the application must protect audit information from unauthorized deletion. This requirement can be achieved through multiple methods which will depend upon system architecture and design.Some commonly employed methods include: ensuring log files enjoy the proper file system permissions utilizing file system protections; restricting access; and backing up log data to ensure log data is retained.Applications providing a user interface to audit data will leverage user permissions and roles identifying the user accessing the data and the corresponding rights the user enjoys in order make access decisions regarding the deletion of audit data.Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity.Deletion of database audit data could mask the theft of, or the unauthorized modification of, sensitive data stored in the database.

Check content

Note: The following instructions use the PGDATA environment variable. See supplementary content APPENDIX-F for instructions on configuring PGDATA. Review locations of audit logs, both internal to the database and database audit logs located at the operating system level. Verify there are appropriate controls and permissions to protect the audit information from unauthorized modification. #### stderr Logging If the PostgreSQL server is configured to use stderr for logging, the logs will be owned by the database administrator (shown here as "postgres") with a default permissions level of 0600. The permissions can be configured in postgresql.conf. To check the permissions for log files in postgresql.conf, as the database administrator (shown here as "postgres"), run the following command: $ sudo su - postgres $ grep "log_file_mode" ${PGDATA?}/postgresql.conf If the permissions are not 0600, this is a finding. Next, navigate to where the logs are stored. This can be found by running the following command against postgresql.conf as the database administrator (shown here as "postgres"): $ sudo su - postgres $ grep "log_directory" ${PGDATA?}/postgresql.conf With the log directory identified, as the database administrator (shown here as "postgres"), list the permissions of the logs: $ sudo su - postgres $ ls -la ${PGDATA?}/pg_log If logs are not owned by the database administrator (shown here as "postgres") and are not the same permissions as configured in postgresql.conf, this is a finding. #### syslog Logging If the PostgreSQL server is configured to use syslog for logging, consult organization syslog setting for permissions and ownership of logs

Fix text

Note: The following instructions use the PGDATA and PGVER environment variables. See supplementary content APPENDIX-F for instructions on configuring PGDATA and APPENDIX-H for PGVER. To change log_timezone in postgresql.conf to use a different time zone for logs, as the database administrator (shown here as "postgres"), run the following:  $ sudo su - postgres  $ vi ${PGDATA?}/postgresql.conf  log_timezone='UTC'  Now, as the system administrator, reload the server with the new configuration: # SYSTEMD SERVER ONLY $ sudo systemctl reload postgresql-${PGVER?} # INITD SERVER ONLY $ sudo service postgresql-${PGVER?} reload

Pro Tips

Powered by sagemincer