Re: "key=" on all related log lines
On Friday, December 18, 2020 8:24:04 AM EST Andreas Hasenack wrote:
I use the -k "sometext" parameter in my audit rules, to
help analyze
the logs. I noticed that it's only added to one of the log lines, not
the others, but the tools (ausearch, aureport) find the other related
entries nevertheless.
Correct.
For example:
-w /etc/shadow -p wa -k shadow-file-changed
After a "# touch /etc/shadow" I get:
type=SYSCALL msg=audit(1608297571.005:160): arch=c000003e syscall=257
success=yes exit=3 a0=ffffff9c a1=7ffedcecb865 a2=941 a3=1b6 items=2
ppid=1623 pid=2382 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=pts1 ses=1 comm="touch" exe="/bin/touch"
key="shadow-file-changed"
type=CWD msg=audit(1608297571.005:160): cwd="/root"
type=PATH msg=audit(1608297571.005:160): item=0 name="/etc/" inode=206
dev=fc:01 mode=040755 ouid=0 ogid=0 rdev=00:00 nametype=PARENT
cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
type=PATH msg=audit(1608297571.005:160): item=1 name="/etc/shadow"
inode=64013 dev=fc:01 mode=0100640 ouid=0 ogid=42 rdev=00:00
nametype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000
cap_fe=0 cap_fver=0
type=PROCTITLE msg=audit(1608297571.005:160):
proctitle=746F756368002F6574632F736861646F77
But only the first line has my key.
Correct.
Are the other entries correlated via the id in "audit(id)"?
They are correlated by the combination of seconds since 1970, millisecond,
and serial number. And the records between two events can be interlaced in
the logs. Nothing in the klernel serializes the output. So, its entirely on
user space to correlate things.
Is there a way to have the key parameter attached to all of them?
No.
I'd like to send to a remote log server only certain events, and
if I filter
by key, I only get one of these log lines.
Then, I'd say you're not doing it the way it was intended. A simple grep is
not sufficient. You would want to use the audit tools or auparse library to do
this for you. They take care of the correlation and de-interlacing of events.
And they can do the filtering. A good example is the setroubleshooter plugin.
It filters just for AVC's and then sees if they have configuration solutions to
avoid the AVC's.
Writing a filre using the auparse library is pretty simple. You can find an
example to start from here:
https://github.com/linux-audit/audit-userspace/blob/master/contrib/plugin/
audisp-example.c
I'd also suggest making any plugin double threaded, with one side dequeuing
events and the other thread processing them and some kind of queue in
between. If the socket buffer between auditd and the plugin gets full, it can
affect the audit daemon's performance.
-Steve