On Tue, Mar 16, 2021 at 5:26 PM Alan Evangelista <alan.vitor(a)gmail.com> wrote:
AFAIK, the purpose of the backlog (a queue of audit events in the kernel) is to assure no
events are lost when events are generated at a faster speed than they are consumed.
I'm using CentOS7 with kernel 3.10.0-1160.15.2.el7.x86_64 and trying to test the
backlog, but it seems it's not working at all.
Audit rule:
-a always,exit -F dir=/sasdata -F arch=b64 -S creat -S open -S openat -S unlink -S
unlinkat -S symlink -S symlinkat -S link -S linkat -S rename -S renameat -S chmod -S
fchmod -S fchmodat -S chown -S fchown -S fchownat -S mkdir -S mkdirat -S rmdir -S setxattr
-S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -k filesystem_op
First I turned auditd off so that events are not consumed:
# service stop auditd
Then I make sure that the backlog size is greater than 0:
# auditctl -s
enabled 1
failure 1
pid 0
rate_limit 5000
backlog_limit 8192
lost 0
backlog 0
loginuid_immutable 0 unlocked
I have run some simple commands in /data that should be logged , e.g. touch file, mkdir
dir. Finally, I have run auditctl-s and expected to see the backlog events counter go up,
but it's still 0. If I start auditd again, the events are never logged. Am I missing
something here?
Thanks in advance.
The audit queue mechanism (backlog) was pretty messed up in older
kernels, and while we've fixed it in modern kernels, I believe that
not all of the changes have been backported to the older distribution
kernels. If you are a RHEL customer you *may* have some luck pursuing
this via your RH/IBM support person, but I can't say for certain (I
don't work for RH/IBM).
From an upstream perspective - which is what this mailing list focuses
on - there isn't much for us to do here unless you are seeing problems
with a more current kernel.
--
paul moore
www.paul-moore.com