5.4 Ensure 'SUPER' is Not Granted to Non-Administrative Users

Information

The SUPER privilege is a powerful and far-reaching privilege and should not be granted lightly. In MariaDB, SUPER is deprecated and will be removed in a future version of MariaDB.

The SUPER privilege shown in the INFORMATION_SCHEMA.USER_PRIVILEGES table governs the use of a variety of MariaDB features. These features include, CHANGE MASTER TO, KILL, mysqladmin kill option, PURGE BINARY LOGS, SET GLOBAL, mysqladmin debug option, logging control, and more.

In MariaDB, SUPER is deprecated and will be removed in a future version of MariaDB. Migrating Accounts from SUPER to Dynamic Privileges is recommended.

Rationale:

The SUPER privilege allows principals to perform many actions, including view and terminate currently executing MariaDB statements (including statements used to manage passwords). This privilege also provides the ability to configure MariaDB, such as enable/disable logging, alter data, disable/enable features. Limiting the accounts that have the SUPER privilege reduces the chances that an attacker can exploit these capabilities.

It is more secure to migrate administrative users off SUPER and instead assign the specific and minimal set of mysql Dynamic Privileges needed to perform their tasks.

Impact:

When the SUPER privilege is denied to a given user, that user will be unable to take advantage of certain capabilities, such as certain mysqladmin options.

NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance.

Solution

Perform the following steps to remediate this setting:

Enumerate the non-administrative users found in the result set of the audit procedure

For each user, issue the following SQL statement (replace <user> with the non-administrative user):

REVOKE SUPER ON *.* FROM '<user>';

Next minimize administrator rights

Assess the minimal set of Dynamic Permissions needed by a user to perform their duties.

For each user assign the appropriate Dynamic Permission and then revoke that <user> SUPER capability.
For example, if administrator 'u1'@'localhost' requires SUPER for binary log purging and system variable modification, these statements make the required changes to the account thus limiting rights to what is needed:

GRANT BINLOG_ADMIN, SYSTEM_VARIABLES_ADMIN ON *.* TO 'u1'@'localhost';
REVOKE SUPER ON *.* FROM 'u1'@'localhost';

See Also

https://workbench.cisecurity.org/benchmarks/16527