V-253733

Discussion

Without auditing the enforcement of access restrictions against changes to configuration, it would be difficult to identify attempted attacks and an audit trail would not be available for forensic investigation for after-the-fact actions. Enforcement actions are the methods or mechanisms used to prevent unauthorized changes to configuration settings. Enforcement action methods may be as simple as denying access to a file based on the application of file permissions (access restriction). Audit items may consist of lists of actions blocked by access restrictions or changes identified after the fact.

Check Content

To verify that system denies are logged when unprivileged users attempt to change database configuration, run the following commands using the database administrator, and a newly created user shown here as test_user: 

MariaDB> CREATE USER 'test_user'@'localhost' IDENTIFIED BY 'TEst_Password!2';
MariaDB> CREATE DATABASE myapp;
MariaDB> CREATE TABLE myapp.mytable (a int, b char(10));

As the newly created test_user, alter the table: 
$ mariadb -u test_user -p
Enter password:
MariaDB> ALTER TABLE mytable ADD COLUMN (c int);

Check the latest log to determine if the denial is logged. For example: 
$ tail -f /var/log/mysql/audit.log
 
20190909 12:14:29,osboxes,test_user9,localhost,21,0,CONNECT,,,0
20190909 12:14:29,osboxes,test_user9,localhost,21,10,QUERY,, alter table myapp.mytable add column (c int) ,1142
20190909 12:14:29,osboxes,test_user9,localhost,21,0,DISCONNECT,,,0

If the denial is not produced, this is a finding.

By default MariaDB configuration files are owned by the OS Administrator user (here root) and cannot be edited by nonprivileged users:

$ ls -la /etc | grep my.cnf
-rw-r--r--.   1 root root      301 Aug 25 12:45 my.cnf

If my.cnf is not owned by the OS administrator (chown here as root) and does not have read and write permissions for the owner, this is a finding.