On Tue, Mar 16, 2021 at 5:26 PM Alan Evangelista <[email protected]> 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 -- Linux-audit mailing list [email protected] https://listman.redhat.com/mailman/listinfo/linux-audit
