On 2021-03-16 18:25, Alan Evangelista 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?
So, since you haven't indicated if you have tried and tested this
already, please start by running those simple commands while the auditd
service is running and verifying that those commands do get logged as
expected. If they don't, fix that first.
- RGB
--
Richard Guy Briggs <rgb(a)redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635