Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.2.18, 10.3.10
-
None
Description
SET queries are only logged in the audit log when server_audit_events=QUERY is set, not with the more specific QUERY_* sub-modes.
So when e.g. using server_audit_events=QUERY_DCL queries that change the logging behavior, like e.g.:
SET global server_audit_logging=0;
|
This way a malicious user with SUPER privileges (but without file system level access to the server config files) could temporarily disable audit logging and then modify data without leaving a real trace.
IMHO queries changing the audit log configuration, so any SET operating on a server_audit_% variable, should appear in the log even if full QUERY mode is not set, or at least be included in QUERY_DCL mode.
Or, alternatively, there should be an option to outright ban any dynamic change of server_audit_% variables, e.g. something like
[mysqld]
|
server_audit_immutable=ON
|
that could be used to remove the DYNAMIC attribute from all audit plugin variables, and so to prevent runtime changes to audit log configuration.
Attachments
Issue Links
- relates to
-
MDEV-19459 Backport MDEV-17456 to server_audit plugin in 10.1
-
- Closed
-
-
-
- Closed
-
-
-
- Open
-
Activity
http://lists.askmonty.org/pipermail/commits/2019-April/013696.html
The SET server_audit_logging=off statement has to be logged always.
Since the server_audit_% system variables can affect the audit logging configuration, it may be a good idea to make "SET GLOBAL" followed by any server_audit_% system variable a special case that is always logged, regardless of the value of server_audit_events. See also MDEV-14713 for a related request.
holyfoot See the last inputs from Support, this is unfortunately not fixed yet for customers.
I executed the following queries in MariaDB 10.2.25:
MariaDB [(none)]> INSTALL SONAME 'server_audit';
|
Query OK, 0 rows affected (0.01 sec)
|
|
|
MariaDB [(none)]> SET GLOBAL server_audit_events='CONNECT';
|
Query OK, 0 rows affected (0.00 sec)
|
|
|
MariaDB [(none)]> SET GLOBAL server_audit_logging=ON;
|
Query OK, 0 rows affected (0.00 sec)
|
|
|
MariaDB [(none)]> SET GLOBAL server_audit_logging=OFF;
|
Query OK, 0 rows affected (0.00 sec)
|
|
|
MariaDB [(none)]> SET GLOBAL server_audit_logging=ON;
|
Query OK, 0 rows affected (0.00 sec)
|
|
|
MariaDB [(none)]> SET GLOBAL server_audit_logging=OFF;
|
Query OK, 0 rows affected (0.00 sec)
|
|
|
MariaDB [(none)]> SET GLOBAL server_audit_excl_users='bob';
|
Query OK, 0 rows affected (0.00 sec)
|
|
|
MariaDB [(none)]> SET GLOBAL server_audit_logging=ON;
|
Query OK, 0 rows affected (0.00 sec)
|
|
|
MariaDB [(none)]> SET GLOBAL server_audit_excl_users='bob,alice';
|
Query OK, 0 rows affected (0.00 sec)
|
|
|
MariaDB [(none)]> \q
|
Bye
|
The audit log only contains the following:
20190621 16:59:27,ip-172-30-0-58.us-west-2.compute.internal,root,localhost,14,5,QUERY,,'SET GLOBAL server_audit_logging=OFF',0
|
20190621 16:59:29,ip-172-30-0-58.us-west-2.compute.internal,root,localhost,14,7,QUERY,,'SET GLOBAL server_audit_logging=OFF',0
|
20190621 17:00:16,ip-172-30-0-58.us-west-2.compute.internal,root,localhost,14,0,DISCONNECT,,,0
|
So it does not look like this has been fixed yet.
Assigned to serg to decide how we conceptually deal with the idea of "malicious SUPER user" from the security point of view. After that it will probably go to holyfoot.