[graphics 06448] [PATCH 2/2] fix a bug that use option '-k key-string' cannot search out all matched logs

[zhangxiliang]

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
> 
> 
>