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

MariaDB must generate audit records when unsuccessful attempts to modify privileges/permissions occur.

DISA Rule

SV-253753r961800_rule

Vulnerability Number

V-253753

Group Title

SRG-APP-000495-DB-000329

Rule Version

MADB-10-010100

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

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"
]
}'
));

Check Contents

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

MariaDB> SHOW GLOBAL STATUS LIKE 'Server_audit_active';

If the MariaDB Enterprise Audit is not active, this is a finding.

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

MariaDB> SELECT * FROM mysql.server_audit_filters;

Verify query_events includes DCL or ALL in corresponding audit filters. If not, this is a finding.

In one terminal, tail the audit log file. For example:
$ tail -F /var/lib/mysql/server_audit.log (default location)

Open a new terminal and connect to the database.

As the database administrator, create a user without special permissions:
MariaDB> CREATE USER 'user_name_here'@'localhost' IDENTIFIED BY 'password_here';

As the database administrator, create a role by running the following SQL:
MariaDB> CREATE ROLE 'role_name_here';

As the database administrator, GRANT role to testuser:
MariaDB> GRANT 'role_name_here' TO 'user_name_here'@'localhost';

As the database administrator, add privileges to user_role for testdb, and add GRANT role to testuser:
MariaDB> GRANT SELECT ON db_name_here TO 'user_name_here'@'localhost';
MariaDB> GRANT SELECT ON db_name_here TO 'role_name_here';

As a regular user, modify privileges for testuser and user_role:
MariaDB> GRANT DELETE ON db_name_here TO 'user_name_here'@'localhost';
MariaDB> GRANT DELETE ON db_name_here TO 'role_name_here';

If the audit records are not produced for unsuccessful attempts to modify privileges/permissions and roles in the first terminal, this is a finding.

Vulnerability Number

V-253753

Documentable

False

Rule Version

MADB-10-010100

Severity Override Guidance

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

MariaDB> SHOW GLOBAL STATUS LIKE 'Server_audit_active';

If the MariaDB Enterprise Audit is not active, this is a finding.

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

MariaDB> SELECT * FROM mysql.server_audit_filters;

Verify query_events includes DCL or ALL in corresponding audit filters. If not, this is a finding.

In one terminal, tail the audit log file. For example:
$ tail -F /var/lib/mysql/server_audit.log (default location)

Open a new terminal and connect to the database.

As the database administrator, create a user without special permissions:
MariaDB> CREATE USER 'user_name_here'@'localhost' IDENTIFIED BY 'password_here';

As the database administrator, create a role by running the following SQL:
MariaDB> CREATE ROLE 'role_name_here';

As the database administrator, GRANT role to testuser:
MariaDB> GRANT 'role_name_here' TO 'user_name_here'@'localhost';

As the database administrator, add privileges to user_role for testdb, and add GRANT role to testuser:
MariaDB> GRANT SELECT ON db_name_here TO 'user_name_here'@'localhost';
MariaDB> GRANT SELECT ON db_name_here TO 'role_name_here';

As a regular user, modify privileges for testuser and user_role:
MariaDB> GRANT DELETE ON db_name_here TO 'user_name_here'@'localhost';
MariaDB> GRANT DELETE ON db_name_here TO 'role_name_here';

If the audit records are not produced for unsuccessful attempts to modify privileges/permissions and roles in the first terminal, this is a finding.

Check Content Reference

M

Target Key

5475