Details
-
Task
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Won't Do
-
None
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.
Attachments
Issue Links
- blocks
-
-
- Closed
-
- includes
-
-
- Closed
-
-
-
- Open
-
-
-
- Closed
-
-
-
- Open
-
- is blocked by
-
-
- Stalled
-
- relates to
-
-
- Open
-
-
-
- Open
-
-
-
- Open
-
-
MDEV-17456 Malicious SUPER user can possibly change audit log configuration without leaving traces
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Open
-
Activity
| Field | Original Value | New Value |
|---|---|---|
| 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 |
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 to include in it: 1. Placeholders instead of the real values for Query Logging. That's needed usually for the security reasons. Particularly important for passwords. 2. Log rotation based on days 3. Filtering by ROLE-s. 4. PRIVILEGES event type. |
| Workflow | defaullt [ 37805 ] | MariaDB v2 [ 43454 ] |
| Workflow | MariaDB v2 [ 43454 ] | MariaDB v3 [ 62556 ] |
| Component/s | Plugin - Audit [ 10131 ] |
| Link | This issue includes MDEV-10299 [ MDEV-10299 ] |
| Link |
This issue blocks |
Could you consider to merge this issue? https://jira.mariadb.org/browse/MDEV-13421
| Link | This issue includes MDEV-13421 [ MDEV-13421 ] |
| Epic Link | PT-73 [ 68549 ] |
| Rank | Ranked higher |
| Priority | Major [ 3 ] | Critical [ 2 ] |
| Status | Open [ 1 ] | In Progress [ 3 ] |
| Fix Version/s | 10.4 [ 22408 ] |
| 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 to include in it: 1. Placeholders instead of the real values for Query Logging. That's needed usually for the security reasons. Particularly important for passwords. 2. Log rotation based on days 3. Filtering by ROLE-s. 4. PRIVILEGES event type. |
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 2. Placeholders instead of the real values for Query Logging. That's needed usually for the security reasons. Particularly important for passwords. 3. Log rotation based on days 4. PRIVILEGES event type. |
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
| Link | This issue relates to MDEV-11109 [ MDEV-11109 ] |
| 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 2. Placeholders instead of the real values for Query Logging. That's needed usually for the security reasons. Particularly important for passwords. 3. Log rotation based on days 4. PRIVILEGES event type. |
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 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. |
| Link |
This issue relates to |
| 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 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. |
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. |
| Link |
This issue includes |
| Link |
This issue blocks |
| Link | This issue relates to MDEV-14713 [ MDEV-14713 ] |
| NRE Projects | RM_104_security | RM_104_security RM_104_postRC |
| Link |
This issue blocks |
| Link |
This issue relates to |
| Link |
This issue relates to |
| Link | This issue relates to MDEV-19458 [ MDEV-19458 ] |
| Fix Version/s | 10.4 [ 22408 ] |
| Epic Link | PT-73 [ 68549 ] |
| Status | In Progress [ 3 ] | Stalled [ 10000 ] |
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.
| Workflow | MariaDB v3 [ 62556 ] | MariaDB v4 [ 131633 ] |
| Assignee | Alexey Botchkov [ holyfoot ] | Dmitry Shulga [ JIRAUSER47315 ] |
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
| Fix Version/s | N/A [ 14700 ] | |
| Assignee | Dmitry Shulga [ JIRAUSER47315 ] | |
| Resolution | Won't Do [ 10201 ] | |
| Status | Stalled [ 10000 ] | Closed [ 6 ] |
What i'd like in 2.0 is:
Happy for this all to be under a the same event server_audit_events=super