From mboxrd@z Thu Jan 1 00:00:00 1970 From: zhangxiliang Subject: Re: [graphics 06448] [PATCH 2/2] fix a bug that use option '-k key-string' cannot search out all matched logs Date: Thu, 31 Jul 2008 17:16:12 +0800 Message-ID: <489182DC.6090806@cn.fujitsu.com> References: <488EADA7.4010209@cn.fujitsu.com> <488FC4D9.5030804@cn.fujitsu.com> <200807300706.19593.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <200807300706.19593.sgrubb@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: audit-list List-Id: linux-audit@redhat.com 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 > > >