V-286212

Discussion

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 because 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 DAC policies are implemented, subjects are not constrained regarding 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 (MAC) policies is still able to operate under the less rigorous constraints of this requirement. Thus, while MAC 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 bound 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 DAC require identity-based access control, that limitation is not required for this use of DAC.

Check Content

Review system documentation to identify the required DAC.

Review the security configuration of the database and MariaDB. If applicable, review the security configuration of the application(s) using the database.

If the DAC defined in the documentation is not implemented in the security configuration, this is a finding.
 
To check the permissions granted to a user use the following queries:
 
SHOW PRIVILEGES;

Run this database query to create the "SHOW GRANTS" script for each user: 

SELECT DISTINCT CONCAT( 'SHOW GRANTS FOR ', user,'@', host,';') AS grantQuery FROM mysql.user WHERE is_role = 'N';
Example output:
+----------------------------------------+
| grantQuery                             |
+----------------------------------------+
| SHOW GRANTS FOR mariadb.sys@localhost; |
| SHOW GRANTS FOR root@localhost;        |

Run each "SHOW GRANTS" command for each user.

Verify that all users have the correct privileges, if they do not, this is a finding. 

Run the following database query to create the "SHOW GRANTS" script for each role. Use the results to show grants on for all roles:

SELECT DISTINCT CONCAT( 'SHOW GRANTS FOR ', user,'@', host,';') AS grantQuery FROM mysql.user WHERE is_role = 'Y';
Example output:
+----------------------------------------+
| grantQuery                             |
+----------------------------------------+
| SHOW GRANTS FOR admin@; |
| SHOW GRANTS FOR app_writer@;        |

Run each "SHOW GRANTS" command for each role.

SELECT * FROM information_schema.APPLICABLE_ROLES;
**To find out if a role has admin_option (Whether the role can be granted by a particular user)
 SELECT * from mysql.roles_mapping;c

Verify that all roles have the correct privileges, if they do not, this is a finding.