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 |
| 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. |
| 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 ] |
| Workflow | MariaDB v3 [ 62556 ] | MariaDB v4 [ 131633 ] |
| Assignee | Alexey Botchkov [ holyfoot ] | Dmitry Shulga [ JIRAUSER47315 ] |
| Fix Version/s | N/A [ 14700 ] | |
| Assignee | Dmitry Shulga [ JIRAUSER47315 ] | |
| Resolution | Won't Do [ 10201 ] | |
| Status | Stalled [ 10000 ] | Closed [ 6 ] |