Detections
Analytics

EP11-00-007300 - EDB Postgres Advanced Server must enforce discretionary access control policies, as defined by the data owner, over defined subjects and objects.

Warning! Audit Deprecated

This audit has been deprecated and will be removed in a future update.

View Next Audit Version

Information

Discretionary Access Control (DAC) is based on the notion that individual users are 'owners' of objects and therefore have discretion over who should be authorized to access the object and in which mode (e.g., read or write). Ownership is usually acquired as a consequence of creating the object or via specified ownership assignment. DAC allows the owner to determine who will have access to objects they control. An example of DAC includes user-controlled table permissions.

When discretionary access control policies are implemented, subjects are not constrained with regard to what actions they can take with information for which they have already been granted access. Thus, subjects that have been granted access to information are not prevented from passing (i.e., the subjects have the discretion to pass) the information to other subjects or objects.

A subject that is constrained in its operation by Mandatory Access Control policies is still able to operate under the less rigorous constraints of this requirement. Thus, while Mandatory Access Control imposes constraints preventing a subject from passing information to another subject operating at a different sensitivity level, this requirement permits the subject to pass the information to any subject at the same sensitivity level.

The policy is bounded by the information system boundary. Once the information is passed outside of the control of the information system, additional means may be required to ensure the constraints remain in effect. While the older, more traditional definitions of discretionary access control require identity-based access control, that limitation is not required for this use of discretionary access control.

NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance.

Solution

Implement the organization's DAC policy in the security configuration of the database and EDB Postgres Advanced Server, and, if applicable, the security configuration of the application(s) using the database.

If an unapproved user or group role is the owner of a database object, change the owner to an approved user or group role using one of the following ALTER SQL commands as appropriate:

 The syntax is:
 ALTER DATABASE <database name> OWNER TO <new_owner>
 ALTER SCHEMA <schema name> OWNER TO <new_owner>
 ALTER TABLE <table name> OWNER TO <new_owner>
 ALTER SEQUENCE <sequence name> OWNER TO <new_owner>
 ALTER VIEW <view name> OWNER TO <new_owner>
 ALTER FUNCTION <function name> (<args>) OWNER TO <new_owner>
 ALTER PROCEDURE <procedure name> (<args>) OWNER TO <new_owner>

 Examples:
 ALTER DATABASE test_db OWNER TO app_admin
 ALTER SCHEMA test_schema OWNER TO app_admin
 ALTER TABLE test_tbl OWNER TO app_admin
 ALTER SEQUENCE test_seq OWNER TO app_admin
 ALTER VIEW test_vw OWNER TO app_admin
 ALTER FUNCTION test_func (p1 numeric, p2 text) OWNER TO app_admin
 ALTER PROCEDURE test_proc (p1 numeric, p2 text) OWNER TO app_admin

If a user or group role has been granted an unapproved role or object privilege, execute the appropriate REVOKE command as documented here:

 http://www.postgresql.org/docs/current/static/sql-revoke.html

See Also

https://dl.dod.cyber.mil/wp-content/uploads/stigs/zip/U_EDB_PGS_Advanced_Server_v11_Windows_V2R2_STIG.zip

Item Details

References: CAT|II, CCI|CCI-002165, Rule-ID|SV-224191r508023_rule, STIG-ID|EP11-00-007300, STIG-Legacy|SV-110301, STIG-Legacy|V-101197, Vuln-ID|V-224191

Plugin: PostgreSQLDB

Control ID: bcd462449910f7d73fd00eac3b8cf1e6294a15f012917098441bca41cfc7764b