* "key=" on all related log lines
@ 2020-12-18 13:24 Andreas Hasenack
2020-12-18 13:44 ` Steve Grubb
0 siblings, 1 reply; 4+ messages in thread
From: Andreas Hasenack @ 2020-12-18 13:24 UTC (permalink / raw)
To: Linux-audit
Hi,
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.
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. Are the other entries correlated
via the id in "audit(id)"? Is there a way to have the key parameter
attached to all of them? 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.
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: "key=" on all related log lines
2020-12-18 13:24 "key=" on all related log lines Andreas Hasenack
@ 2020-12-18 13:44 ` Steve Grubb
2020-12-18 20:03 ` [EXT] " Wieprecht, Karen M.
0 siblings, 1 reply; 4+ messages in thread
From: Steve Grubb @ 2020-12-18 13:44 UTC (permalink / raw)
To: Andreas Hasenack; +Cc: Linux-audit
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: [EXT] Re: "key=" on all related log lines
2020-12-18 13:44 ` Steve Grubb
@ 2020-12-18 20:03 ` Wieprecht, Karen M.
2020-12-18 20:47 ` Steve Grubb
0 siblings, 1 reply; 4+ messages in thread
From: Wieprecht, Karen M. @ 2020-12-18 20:03 UTC (permalink / raw)
To: Steve Grubb, Andreas Hasenack; +Cc: Linux-audit
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-bounces@redhat.com <linux-audit-bounces@redhat.com> On Behalf Of Steve Grubb
Sent: Friday, December 18, 2020 8:44 AM
To: Andreas Hasenack <andreas@canonical.com>
Cc: Linux-audit@redhat.com
Subject: [EXT] Re: "key=" on all related log lines
APL external email warning: Verify sender linux-audit-bounces@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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [EXT] Re: "key=" on all related log lines
2020-12-18 20:03 ` [EXT] " Wieprecht, Karen M.
@ 2020-12-18 20:47 ` Steve Grubb
0 siblings, 0 replies; 4+ messages in thread
From: Steve Grubb @ 2020-12-18 20:47 UTC (permalink / raw)
To: Wieprecht, Karen M.; +Cc: Linux-audit
Hello,
On Friday, December 18, 2020 3:03:07 PM EST Wieprecht, Karen M. wrote:
> 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.
-k keyname and -F key=keyname are equivalent. The -k variant started
life as syntax for watches. Later, this was expanded so that syscall rules
can also have keys.
> 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).
Not really. They are equivalent. In both cases they are saying that if the
rest of the rule matches, add this label to the event so that its meaning can
be better understood.
> 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
What this is saying is that if any of these trigger, it is affecting the
system locale in some way. It can be either by changing the hostname's
identity, changing how it advertises itself at login, or changing what it
uses to identify itself in syslog. This group of rules act as a team that
watches different variations of the same issue.
> 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?
Nope. This set of rules will flood your system on dnf update. They are very
much alive and well. :-)
> 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?
As mentioned above, the key is a label assigned when the rest of the rule
matches. This label is not used for filtering in the kernel. It is used for
filtering in reports, searches, and some realtime analysis tools such as the
now defunct prelude-ids audisp-plugin.
For example, when I am wondering what has been happening in a system since
the last time I looked, I run the key report:
aureport --start yesterday --key --summary -i
Then I might decide one key is odd and I want to investigate its origin
ausearch --start yesterday -k power-abuse --raw | aureport --user -i
ausearch --start yesterday -k power-abuse --raw | aureport --file -i
If you have keys on all your rules, you can tell which ones are things you
are interested in versus events that are automatically generated because they
are hardwired, such as login. Automatically generated do not have keys.
-Steve
> -----Original Message-----
> From: linux-audit-bounces@redhat.com <linux-audit-bounces@redhat.com> On
> Behalf Of Steve Grubb
Sent: Friday, December 18, 2020 8:44 AM
> To: Andreas Hasenack <andreas@canonical.com>
> Cc: Linux-audit@redhat.com
> Subject: [EXT] Re: "key=" on all related log lines
>
> APL external email warning: Verify sender linux-audit-bounces@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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-12-18 20:47 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-18 13:24 "key=" on all related log lines Andreas Hasenack
2020-12-18 13:44 ` Steve Grubb
2020-12-18 20:03 ` [EXT] " Wieprecht, Karen M.
2020-12-18 20:47 ` Steve Grubb
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.