It's funny that this topic came up today, I just emailed my team on Monday
about some concerns I have regarding the difference between -k keyname and
key=keyname in the audit.rules files. If I understand this correctly, some
rules assign a keyname with –k keyname, and other rules use those assigned
keynames to filter/limit the scope of the rule (-F key=keyname). If this is
correct, I believe we may have some rules in the sample 30-stig.rules that
would never generate the keyname they are filtering against. Perhaps this is
in error? For example:
For instance, in the case of system-locale, there are some rules are assigning
the keyname with "-k system-locale” to certain events and other rules
filtering what is collected based on –F key=system-locale, so this one may be
ok
-a always,exit -F arch=b32 -S sethostname,setdomainname -F
key=system-locale
-a always,exit -F arch=b64 -S sethostname,setdomainname -F
key=system-locale
-w /etc/issue -p wa -k system-locale
-w /etc/issue.net -p wa -k system-locale
-w /etc/hosts -p wa -k system-locale
-w /etc/hostname -p wa -k system-locale
-a always,exit -F dir=/etc/NetworkManager/ -F perm=wa -F
key=system-locale
However, in the case of perm_mod, there are no rules assigning the keyname
with "-k perm_mod", so I suspect that nothing will ever be collected for the
rules that are filtering based on perm_mod:
-a always,exit -F arch=b32 -S chmod,fchmod,fchmodat -F auid>=1000 -F
auid!=unset -F key=perm_mod
-a always,exit -F arch=b64 -S chmod,fchmod,fchmodat -F auid>=1000 -F
auid!=unset -F key=perm_mod
-a always,exit -F arch=b32 -S lchown,fchown,chown,fchownat -F
auid>=1000 -F auid!=unset -F key=perm_mod
-a always,exit -F arch=b64 -S chown,fchown,lchown,fchownat -F
auid>=1000 -F auid!=unset -F key=perm_mod
-a always,exit -F arch=b32 -S
setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F
auid>=1000 -F auid!=unset -F key=perm_mod
-a always,exit -F arch=b64 -S
setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F
auid>=1000 -F auid!=unset -F key=perm_mod
Is this correct? If so, we may need to make some corrections so related events
get assigned the perm_mod keyname , and correct any other similar issues that
may exist. If not, can you explain how events wouold be generated with the
perm_mod keyname?
Thanks so much,
Karen Wieprecht
-----Original Message-----
From: linux-audit-boun...@redhat.com <linux-audit-boun...@redhat.com> On Behalf
Of Steve Grubb
Sent: Friday, December 18, 2020 8:44 AM
To: Andreas Hasenack <andr...@canonical.com>
Cc: Linux-audit@redhat.com
Subject: [EXT] Re: "key=" on all related log lines
APL external email warning: Verify sender linux-audit-boun...@redhat.com before
clicking links or attachments
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
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
