Re: [graphics 06448] [PATCH 2/2] fix a bug that use option '-k key-string' cannot search out all matched logs
Hello Steve,
Thanks for your detailed explanation.
But I found two cases for "CONFIG_CHANGE" message miss "key" field.
for example1:
1. # touch temp_file
2. # auditctl -w `pwd`/temp_file -k temp_file
3. # rm -f temp_file
The "CONFIG_CHANGE" message is "type=CONFIG_CHANGE
msg=audit(1217667917.265:1027): op=updated rules specifying
path="/root/temp_file" with dev=4294967295 ino=4294967295 list=0 res=1".
for example2:
1. # auditctl -e 2
2. # auditctl -a exit,always -S open -k temp_file
The "CONFIG_CHANGE" message is "type=CONFIG_CHANGE
msg=audit(1217668048.831:1031): user pid=13202 uid=0 auid=0 ses=1
subj=root:system_r:auditctl_t:s0-s0:c0.c1023 audit_enabled=2 res=0".
Are they OK or error?
Steve Grubb said the following on 2008-07-30 19:06:
On Tuesday 29 July 2008 21:33:13 zhangxiliang wrote:
>> echo 'node=RHEL5.2GA type=CONFIG_CHANGE msg=audit(1217404709.683:23182):
>> auid=0 subj=root:system_r:auditctl_t:s0-s0:c0.c1023 op=remove rule
>> key="haha" list=4 res=1'
> Why the message which type is "CONFIG_CHANGE" contains "key"
field?
> The "CONFIG_CHANGE" audit message should only describe the audit object
> status.
The reason that the key field is output is an attempt at telling the security
officer more about which rule was deleted. Yes at the commandline you know
what rules you just deleted, but if all you have is the logs and it happened
some time in the past, how do you know *exactly* which rule was deleted? This
gets us closer without having to write something in the kernel that iterates
through the fields and changes them to text. We really can't do that in the
kernel.
-Steve