On Tue, Jun 16, 2020 at 12:58 AM Max Englander <[email protected]> wrote: > > In environments where security is prioritized, users may set > --backlog_wait_time to a high value in order to reduce the likelihood > that any audit event is lost, even though doing so may result in > unpredictable performance if the kernel schedules a timeout when the > backlog limit is exceeded. For these users, the next best thing to > predictable performance is the ability to quickly detect and react to > degraded performance. This patch proposes to aid the detection of kernel > audit subsystem pauses through the following changes: > > Add a variable named audit_backlog_warn_time. Enforce the value of this > variable to be no less than zero, and no more than the value of > audit_backlog_wait_time. > > If audit_backlog_warn_time is greater than zero and if the total time > spent waiting to enqueue an audit record is greater than or equal to > audit_backlog_warn_time, then print a warning with the total time > spent waiting. > > An example configuration: > > auditctl --backlog_warn_time 50 > > An example warning message: > > audit: sleep_time=52 >= audit_backlog_warn_time=50 > > Tested on Ubuntu 18.04.04 using complementary changes to the audit > userspace: https://github.com/linux-audit/audit-userspace/pull/131. > > Signed-off-by: Max Englander <[email protected]> > --- > include/uapi/linux/audit.h | 7 ++++++- > kernel/audit.c | 35 +++++++++++++++++++++++++++++++++++ > 2 files changed, 41 insertions(+), 1 deletion(-)
If an admin is prioritizing security, aka don't loose any audit records, and there is a concern over variable system latency due to an audit queue backlog, why not simply disable the backlog limit? -- paul moore www.paul-moore.com -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
