STIGQter STIGQter: STIG Summary: MariaDB Enterprise 10.x Security Technical Implementation Guide Version: 2 Release: 5 Benchmark Date: 01 Apr 2026:

MariaDB must produce audit records of its enforcement of access restrictions associated with changes to the configuration of the DBMS or database(s).

DISA Rule

SV-253733r1018602_rule

Vulnerability Number

V-253733

Group Title

SRG-APP-000381-DB-000361

Rule Version

MADB-10-008000

Severity

CAT II

CCI(s)

Weight

10

Fix Recommendation

The MariaDB Enterprise Audit plugin can be configured to audit these changes.

Update necessary audit filters to include query_event ALL. Example:

MariaDB> DELETE FROM mysql.server_audit_filters WHERE filtername = 'default';

MariaDB> INSERT INTO mysql.server_audit_filters (filtername, rule)
VALUES ('default',
JSON_COMPACT(
'{
"connect_event": [
"CONNECT",
"DISCONNECT"
],
"query_event": [
"ALL"
]
}'
));

If the config files are not secured properly in the file system, change the ownership and permissions with operating system operations.

Example:

chown root:root /etc/my.cnf.d
chmod 644 /etc/my.cnf.d

Check Contents

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.

Vulnerability Number

V-253733

Documentable

False

Rule Version

MADB-10-008000

Severity Override Guidance

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.

Check Content Reference

M

Target Key

5475