[MDEV-5983] Auditing plugin v2.0 Created: 2014-03-30  Updated: 2023-04-24  Resolved: 2023-04-24

Status: Closed
Project: MariaDB Server
Component/s: Plugin - Audit
Fix Version/s: N/A

Type: Task Priority: Critical
Reporter: Alexey Botchkov Assignee: Unassigned
Resolution: Won't Do Votes: 8
Labels: None

Issue Links:
Blocks
blocks MDEV-10040 Audit plugin, Add functionality to fi... Closed
is blocked by MDEV-5313 Improving audit api Stalled
PartOf
includes MDEV-5245 Audit plugin reveals user lists to un... Closed
includes MDEV-10299 Make server_audit plugin support roles Open
includes MDEV-12494 Include or exclude host names from au... Closed
includes MDEV-13421 Improvement for Server Audit Plugin O... Open
Relates
relates to MDEV-5212 Role support for Audit Plugin API Open
relates to MDEV-11109 Make server_audit_excl_users have eff... Open
relates to MDEV-14713 MariaDB Audit Plugin audits SET GLOBAL Open
relates to MDEV-17456 Malicious SUPER user can possibly cha... Closed
relates to MDEV-19442 server_audit plugin doesn't consider ... Closed
relates to MDEV-19443 server_audit plugin doesn't log proxy... Closed
relates to MDEV-19458 server_audit plugin should log when t... Open

 Description   

The set of desired features for the Auditing Plugin is big enough.
And we need to recode the existing plugin significantly to make it all working.
So v2.0

Features planned to include in it:
1. filter rules defined per user/role using a system table

  • this will make the parameters server_audit_events, server_audit_excl_users and server_audit_incl_users obsolete
  • thew default behavior without having filter rules defined will be to log all events and for all users
  • user should be user@host for different filtering per host

2. Propagating Auditing Setting to log files
For Auditing it is of value to know the settings an audit log is based on.
When creating a new file, current settings should be added. A new event type could be used, like AUDIT_CONFIG and can be enabled via a system variable.

In the same format current used for the auditing rows it could look like:

20180307 22:57:20,,,,,,AUDIT_CONFIG,,'server_audit_syslog_priority=LOG_INFO',0

3. Logging for changes of auditing settings
As audit logging settings can be changed dynamically, should be possible to log changes to the audit settings itself, although events like QUERY are disabled ( a SET command used). The same format could be used as above, but just reporting the new value.

4. Placeholders instead of the real values for Query Logging.
That's needed usually for the security reasons. Particularly important for passwords.

5. Log rotation based on days

6. PRIVILEGES event type.

 Comments   
Comment by Daniel Black [ 2015-11-10 ]

What i'd like in 2.0 is:

  • global variable changes
  • flush status
  • grants/revokes/create user/alter user/drop user
  • replication changes (CHANGE MASTER, STOP SLAVE..., START SLAVE) though some of these are in general error log they aren't tied to a user.
  • generally anything that required a SUPER priv

Happy for this all to be under a the same event server_audit_events=super

Comment by Su, Jun-Ming [ 2017-11-01 ]

Could you consider to merge this issue? https://jira.mariadb.org/browse/MDEV-13421

Comment by Ralf Gebhardt [ 2018-10-10 ]

MDEV-11109 includes to be able to also exclude CONNECT events from logging for given users. With having user/role based filters the event CONNECT also can be excluded from logging them

Comment by Ricky [ 2021-09-19 ]

Placeholders

>Placeholders instead of the real values for Query Logging.
>That's needed usually for the security reasons. Particularly important for passwords.

I think this is a great idea! Our current use case involves the audit plugin to provide visibility of the queries executed against our databases for our data engineers. Ideally, we would like for the audit logs to be scrubbed of any sensitive data (not just passwords) before they leave our servers. Having this query redaction as first class support would be brilliant. Some sort of query fingerprinting, similar to what mysqldumpslow generates is perfect for our use case.

Friendlier log format

On a similar note, I have tried to parse the FILE format audit logs myself to redact queries and have found it difficult due to the log format. The format could be mistaken for CSV parsable but due to "object" portion of the log format appearing in single quotes it trips us many parsers which strictly adhere to RFC 4180. I see there is a ticket open requesting JSON support - https://jira.mariadb.org/browse/MDEV-17879. I would be interested in any improvement which makes machine parsing of these logs more straightforward.

Is it worthwhile to have a separate ticket tracking any of these requests? Many thanks.

Comment by Ralf Gebhardt [ 2023-04-24 ]

I am closing this task, which was a collection for possible new features for the audit plugin. Separate tasks might be created

1. filter rules defined per user/role using a system table
2. Propagating Auditing Setting to log files
3. Logging for changes of auditing settings

Implemented as a new feature available in MariaDB Enterprise Audit

4. Placeholders instead of the real values for Query Logging.
That's needed usually for the security reasons. Particularly important for passwords.
5. Log rotation based on days
6. PRIVILEGES event type.

Will be reviewed and separate tasks created

Generated at Thu Feb 08 07:08:30 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.