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

MariaDB must be able to generate audit records when unsuccessful attempts to retrieve privileges/permissions occur.

DISA Rule

SV-253673r960885_rule

Vulnerability Number

V-253673

Group Title

SRG-APP-000091-DB-000325

Rule Version

MADB-10-000800

Severity

CAT II

CCI(s)

• CCI-000172 - Generate audit records for the event types defined in AU-2 c that include the audit record content defined in AU-3.

Weight

10

Fix Recommendation

Verify the MariaDB Enterprise Audit plugin is loaded and actively logging:

MariaDB> SHOW GLOBAL STATUS LIKE 'Server_audit_active';

Check what filters are in place by running the following as an administrative user:

MariaDB> SELECT * FROM mysql.server_audit_filters;

Update the filters as necessary.

Check Contents

As the database administrator, create a user by running the following SQL:

MariaDB> CREATE USER 'test_user'@'localhost' IDENTIFIED BY 'test_user_password';

In one terminal, tail the audit log file:

tail -F /var/lib/mysql/server_audit.log (default location)

In another terminal attempt to retrieve information from the MariaDB table, mysql.roles_mapping, by logging in as the test_user and running a query which it does not have privileges to do, for example:

$ mariadb -u test_user -p

MariaDB> SELECT * FROM mysql.roles_mapping;

The audit log will show:
20190321 21:39:20,5a7e16cc51f7, test_user ,localhost,127,394,QUERY,, select * from mysql.roles_mapping ,1142

To find failed queries, look for two elements: The notation indicating that it is a QUERY entry, and the last value for the entry. If the query is unsuccessful, the value will be NOT EQUAL TO 0.

If the above steps cannot verify that audit records are produced when MariaDB denies retrieval of privileges/permissions/role memberships, this is a finding.

If an audit record is not produced in the first terminal, this is a finding.

Vulnerability Number

V-253673

Documentable

False

Rule Version

MADB-10-000800

Severity Override Guidance

As the database administrator, create a user by running the following SQL:

MariaDB> CREATE USER 'test_user'@'localhost' IDENTIFIED BY 'test_user_password';

In one terminal, tail the audit log file:

tail -F /var/lib/mysql/server_audit.log (default location)

In another terminal attempt to retrieve information from the MariaDB table, mysql.roles_mapping, by logging in as the test_user and running a query which it does not have privileges to do, for example:

$ mariadb -u test_user -p

MariaDB> SELECT * FROM mysql.roles_mapping;

The audit log will show:
20190321 21:39:20,5a7e16cc51f7, test_user ,localhost,127,394,QUERY,, select * from mysql.roles_mapping ,1142

To find failed queries, look for two elements: The notation indicating that it is a QUERY entry, and the last value for the entry. If the query is unsuccessful, the value will be NOT EQUAL TO 0.

If the above steps cannot verify that audit records are produced when MariaDB denies retrieval of privileges/permissions/role memberships, this is a finding.

If an audit record is not produced in the first terminal, this is a finding.

Check Content Reference

M

Target Key

5475