STIGQter: STIG Summary: Crunchy Data PostgreSQL Security Technical Implementation Guide Version: 1 Release: 1 Benchmark Date: 20 Nov 2020: STIGQter: STIG Summary: Crunchy Data PostgreSQL Security Technical Implementation Guide Version: 1 Release: 1 Benchmark Date: 20 Nov 2020:SV-233546r617333_rule
V-233546
SRG-APP-000233-DB-000124
CD12-00-004000
CAT II
10
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 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.
V-233546
False
CD12-00-004000
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.
M
5254