On Tue, Jun 16, 2020 at 12:58 AM Max Englander <max.englander(a)gmail.com> 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 <max.englander(a)gmail.com>
---
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