STIGQter: STIG Summary: PostgreSQL 9.x Security Technical Implementation Guide Version: 2 Release: 1 Benchmark Date: 23 Oct 2020:

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

DISA Rule

SV-214083r508027_rule

Vulnerability Number

V-214083

Group Title

SRG-APP-000118-DB-000059

Rule Version

PGS9-00-004200

Severity

CAT II

CCI(s)

• CCI-000162 - The information system protects audit information from unauthorized access.

Weight

10

Fix Recommendation

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 ensure that logging is enabled, review supplementary content APPENDIX-C for instructions on enabling logging. 

#### syslog Logging 

If PostgreSQL is configured to use syslog for logging, consult organization location and permissions for syslog log files. 

#### stderr Logging 

If PostgreSQL is configured to use stderr for logging, permissions of the log files can be set in postgresql.conf. 

As the database administrator (shown here as "postgres"), edit the following settings of logs in the postgresql.conf file: 

Note: Consult the organization's documentation on acceptable log privileges. 

$ sudo su - postgres 
$ vi ${PGDATA?}/postgresql.conf 
log_file_mode = 0600 

Next, 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

Check Contents

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 access. 

#### syslog Logging 

If PostgreSQL is configured to use syslog for logging, consult organization location and permissions for syslog log files. 

#### stderr Logging 

As the database administrator (shown here as "postgres"), check the current log_file_mode configuration by running the following: 

Note: Consult the organization's documentation on acceptable log privileges. 

$ sudo su - postgres 
$ psql -c "SHOW log_file_mode" 

If log_file_mode is not 600, this is a finding. 

Next, check the current log_destination path by running the following SQL: 

Note: This is relative to PGDATA. 

$ psql -c "SHOW log_destination" 

Next, verify the log files have the set configurations in the log_destination: 

Note: Use location of logs from log_directory. 

$ ls -l ${PGDATA?}/pg_log/ 
total 32 
-rw-------. 1 postgres postgres 0 Apr 8 00:00 postgresql-Fri.log 
-rw-------. 1 postgres postgres 8288 Apr 11 17:36 postgresql-Mon.log 
-rw-------. 1 postgres postgres 0 Apr 9 00:00 postgresql-Sat.log 
-rw-------. 1 postgres postgres 0 Apr 10 00:00 postgresql-Sun.log 
-rw-------. 1 postgres postgres 16212 Apr 7 17:05 postgresql-Thu.log 
-rw-------. 1 postgres postgres 1130 Apr 6 17:56 postgresql-Wed.log 

If logs with 600 permissions do not exist in log_destination, this is a finding.

Vulnerability Number

V-214083

Documentable

False

Rule Version

PGS9-00-004200

Severity Override Guidance

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 access. 

#### syslog Logging 

If PostgreSQL is configured to use syslog for logging, consult organization location and permissions for syslog log files. 

#### stderr Logging 

As the database administrator (shown here as "postgres"), check the current log_file_mode configuration by running the following: 

Note: Consult the organization's documentation on acceptable log privileges. 

$ sudo su - postgres 
$ psql -c "SHOW log_file_mode" 

If log_file_mode is not 600, this is a finding. 

Next, check the current log_destination path by running the following SQL: 

Note: This is relative to PGDATA. 

$ psql -c "SHOW log_destination" 

Next, verify the log files have the set configurations in the log_destination: 

Note: Use location of logs from log_directory. 

$ ls -l ${PGDATA?}/pg_log/ 
total 32 
-rw-------. 1 postgres postgres 0 Apr 8 00:00 postgresql-Fri.log 
-rw-------. 1 postgres postgres 8288 Apr 11 17:36 postgresql-Mon.log 
-rw-------. 1 postgres postgres 0 Apr 9 00:00 postgresql-Sat.log 
-rw-------. 1 postgres postgres 0 Apr 10 00:00 postgresql-Sun.log 
-rw-------. 1 postgres postgres 16212 Apr 7 17:05 postgresql-Thu.log 
-rw-------. 1 postgres postgres 1130 Apr 6 17:56 postgresql-Wed.log 

If logs with 600 permissions do not exist in log_destination, this is a finding.

Check Content Reference

M

Target Key

3994

Comments