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

PostgreSQL must isolate security functions from non-security functions.

DISA Rule

SV-214081r508027_rule

Vulnerability Number

V-214081

Group Title

SRG-APP-000233-DB-000124

Rule Version

PGS9-00-004000

Severity

CAT II

CCI(s)

Weight

10

Fix Recommendation

Do not locate security-related database objects with application tables or schema.

Review any site-specific applications security modules built into the database: determine what schema they are located in and take appropriate action.

Do not grant access to pg_catalog or information_schema to anyone but the database administrator(s). Access to the database administrator account(s) must not be granted to anyone without official approval.

Check Contents

Check PostgreSQL settings to determine whether objects or code implementing security functionality are located in a separate security domain, such as a separate database or schema created specifically for security functionality.

By default, all objects in pg_catalog and information_schema are owned by the database administrator.

To check the access controls for those schemas, as the database administrator (shown here as "postgres"), run the following commands to review the access privileges granted on the data dictionary and security tables, views, sequences, functions and trigger procedures:

$ sudo su - postgres
$ psql -x -c "\dp pg_catalog.*"
$ psql -x -c "\dp information_schema.*"

Repeat the \dp statements for any additional schemas that contain locally defined security objects.

Repeat using \df+*.* to review ownership of PostgreSQL functions:

$ sudo su - postgres
$ psql -x -c "\df+ pg_catalog.*"
$ psql -x -c "\df+ information_schema.*"

Refer to the PostgreSQL online documentation for GRANT for help in interpreting the Access Privileges column in the output from \du. Note that an entry starting with an equals sign indicates privileges granted to Public (all users). By default, most of the tables and views in the pg_catalog and information_schema schemas can be read by Public.

If any user besides the database administrator(s) is listed in access privileges and not documented, this is a finding.

If security-related database objects or code are not kept separate, this is a finding.

Vulnerability Number

V-214081

Documentable

False

Rule Version

PGS9-00-004000

Severity Override Guidance

Check PostgreSQL settings to determine whether objects or code implementing security functionality are located in a separate security domain, such as a separate database or schema created specifically for security functionality.

By default, all objects in pg_catalog and information_schema are owned by the database administrator.

To check the access controls for those schemas, as the database administrator (shown here as "postgres"), run the following commands to review the access privileges granted on the data dictionary and security tables, views, sequences, functions and trigger procedures:

$ sudo su - postgres
$ psql -x -c "\dp pg_catalog.*"
$ psql -x -c "\dp information_schema.*"

Repeat the \dp statements for any additional schemas that contain locally defined security objects.

Repeat using \df+*.* to review ownership of PostgreSQL functions:

$ sudo su - postgres
$ psql -x -c "\df+ pg_catalog.*"
$ psql -x -c "\df+ information_schema.*"

Refer to the PostgreSQL online documentation for GRANT for help in interpreting the Access Privileges column in the output from \du. Note that an entry starting with an equals sign indicates privileges granted to Public (all users). By default, most of the tables and views in the pg_catalog and information_schema schemas can be read by Public.

If any user besides the database administrator(s) is listed in access privileges and not documented, this is a finding.

If security-related database objects or code are not kept separate, this is a finding.

Check Content Reference

M

Target Key

3994

Comments