From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: [RFC] Do away with entry filter Date: Tue, 28 Jul 2009 14:26:13 -0400 Message-ID: <200907281426.14073.sgrubb@redhat.com> References: <200902270954.12237.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Return-path: Received: from centaur.localnet (vpn-10-137.bos.redhat.com [10.16.10.137]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n6SIPhDa025940 for ; Tue, 28 Jul 2009 14:25:43 -0400 In-Reply-To: <200902270954.12237.sgrubb@redhat.com> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com List-Id: linux-audit@redhat.com Hello, Just as a reminder to everyone, this proposal has been put in svn trunk as commit #300. I hope to have audit 2.0 out later this week. -Steve On Friday 27 February 2009 09:54:11 am Steve Grubb wrote: > I will be forking the user space audit code soon to start the next major > series. I have a couple thoughts I'd like to share with people to see what > they think. > > The first item is doing away with the entry filter for syscall auditing. > You normally run across this filter when you write rules such as: > > -a always,entry -S open > > The reason I think we can do away with it is that its purpose has changed. > Way back in the early days 2.6.6 -> 2.6.15 kernels, there was this notion > that the audit code could be made to have little impact on the performance > of the system if we give hints about what is needed by using "possible" > actions. > > The problem with "possible" was that people forgot to use it and had exit > filter rules that had no data to operate on. So, we changed the kernel to > always collect the data it needed in case an exit filter would trigger an > event. This was optimized and performance was pretty good. So, that kind of > left the entry filter without a purpose. > > Any entry rule can be written as an exit rule. But not every exit rule can > be written as an entry rule. So the logical choice is to consolidate on the > exit filter. The reason to do this is to improve performance. If we have an > entry rule that triggers, it marks the syscall excursion as auditable. When > we get to the exit filter, it iterates over the whole set of rules even > though the event is auditable. This is because there could be a never rule > that would suppress the output. Another problem introduced by having two > filters is that some fields are not available in the entry filter (exit for > example), it adds complexity in the auditctl program and the in-kernel rule > parser to look for these errors. > > The way that we could make the change is for the audit package to silently > convert entry rules to exit in user space. It could output a warning that > entry rules are being converted and the admin should make the necessary > adjustments. Then after some time has elapsed so that distros have all > updated, drop support in the kernel for the entry filter. > > Let's discuss... > > Thanks, > -Steve