STIGhubSTIGhub
STIGhub— A free STIG search and compliance tool·STIGs updated 4 hours ago
Powered by Pylon·Privacy·Terms·Feedback·© 2026 Beacon Cloud Solutions, Inc.
← Back to MariaDB Enterprise Server Security Technical Implementation Guide

V-286173

CAT I (High)

MariaDB must enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies.

Rule ID

SV-286173r1291813_rule

STIG

MariaDB Enterprise Server Security Technical Implementation Guide

Version

V1R1

CCIs

CCI-000213

Discussion

Authentication with a DoW-approved PKI certificate does not necessarily imply authorization to access MariaDB. To mitigate the risk of unauthorized access to sensitive information by entities that have been issued certificates by DoW-approved PKIs, all DoW systems, including databases, must be properly configured to implement access control policies. Successful authentication must not automatically give an entity access to an asset or security boundary. Authorization procedures and controls must be implemented to ensure each authenticated entity also has a validated and current authorization. Authorization is the process of determining whether an entity, once authenticated, is permitted to access a specific asset. Information systems use access control policies and enforcement mechanisms to implement this requirement. Access control policies include identity-based policies, role-based policies, and attribute-based policies. Access enforcement mechanisms include access control lists, access control matrices, and cryptography. These policies and mechanisms must be employed by the application to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, and domains) in the information system. This requirement is applicable to access control enforcement applications, a category that includes database management systems. If MariaDB does not follow applicable policy when approving access, it may be in conflict with networks or other applications in the information system. This may result in users either gaining or being denied access inappropriately and in conflict with applicable policy.

Check Content

As the DBA, check the privileges of all users and roles in the database.

Find all users:

MariaDB> SELECT user, host FROM mysql.user WHERE is_role = 'N';

Find all roles:

MariaDB> SELECT user FROM mysql.user WHERE is_role = 'Y';

For each user found, check grants:

MariaDB> SHOW GRANTS FOR 'username'@'host';

For each role found, check grants: 

MariaDB> SHOW GRANTS FOR 'rolename';

Review all users and roles and their associated privileges. If any users and/or roles privileges exceed those documented, this is a finding.

As the DBA, check the configured authentication settings:

MariaDB> SHOW PLUGINS;

Find users not using PAM plugin for authentication: 

MariaDB> SELECT user, host, plugin FROM mysql.user WHERE plugin != 'pam';

If any users are returned, this is a finding. 

Review all entries and their associated authentication methods. If any entries do not have their documented authentication requirements, this is a finding.

Fix Text

Create and/or maintain documentation of each group roles appropriate permissions on database objects. 

Implement these permissions in the database and remove any permissions that exceed those documented.
 
The following are examples of how to use role privileges in MariaDB to enforce access controls. Run these as the DBA. For a complete list of privileges, refer to the official documentation at https://mariadb.com/kb/en/grant/.

#### Roles Example 1:
This example demonstrates how to create an admin role with SHUTDOWN privileges.

As the DBA, run:

MariaDB> CREATE ROLE admin;
MariaDB> GRANT SHUTDOWN ON *.* TO admin;

#### Roles Example 2:
This example demonstrates how to create a user make the user a member of the admin role.

As the DBA, run:

MariaDB> CREATE USER 'admin_user'@'host' IDENTIFIED VIA PAM;
MariaDB> GRANT admin TO 'admin_user'@'%';

#### Roles Example 3:
The following demonstrates how to revoke privileges from a role using REVOKE.

As the DBA, run:

MariaDB> REVOKE admin FROM 'admin_user'@'host';

#### Roles Example 4:
The following demonstrates how to modify privileges for a role using GRANT.

As the DBA, run:

MariaDB> GRANT PROCESS ON *.* TO admin;

The following are examples of how to use grant privileges in MariaDB to enforce access controls on objects.

#### Grant Example 1:
This example demonstrates how to grant INSERT on a table to a role.

As the DBA, run:

MariaDB> GRANT INSERT ON test.t1 TO admin;

#### Grant Example 2:
This example demonstrates how to grant ALL PRIVILEGES on a table to a role.

As the DBA, run:

MariaDB> GRANT ALL PRIVILEGES ON test.t1 TO admin;

#### Grant Example 3:
This example demonstrates how to grant a role to a role.

As the DBA, run:

MariaDB> CREATE ROLE admin_master;
MariaDB> GRANT admin TO admin_master;

#### Revoke Example:
This example demonstrates how to revoke access from a role.

As the DBA, run:

MariaDB> REVOKE PROCESS ON *.* FROM admin;

To change authentication requirements for the database, as the OS administrator, review the configuration files "/etc/pam.d" and "/etc/pam.conf". 

After making changes to the configuration files "/etc/pam.d" and "/etc/pam.conf", reload the server:

# SYSTEMD SERVER ONLY
$ sudo systemctl reload mariadb
# INITD SERVER ONLY
$ sudo service mariadb reload