From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Dennis Subject: Re: [PATCH] Add End of Event record Date: Thu, 27 Sep 2007 12:50:15 -0400 Message-ID: <1190911815.15596.43.camel@finch.boston.redhat.com> References: <200709270916.43149.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <200709270916.43149.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: Linux Audit List-Id: linux-audit@redhat.com On Thu, 2007-09-27 at 09:16 -0400, Steve Grubb wrote: > Hi, > > This patch adds an end of event record type. It will be sent by the kernel as > the last record when a multi-record event is triggered. This will aid realtime > analysis programs since they will now reliably know they have the last record > to complete an event. The audit daemon filters this and will not write it to > disk. First let me say AUDIT_EOE is a good idea and I'm glad it's been added, but I'd like to make a couple of observations to put it context. How would a program determine AUDIT_EOE might be present in the audit "protocol" since there is no versioning of the "protocol" (using the term protocol loosely here, but in many respects streaming audit data is a protocol). Unless I'm mistaken the only way to determine if the protocol supports AUDIT_EOE is to watch for it and if it appears in the audit stream set a flag indicating event closure is determined by AUDIT_EOE as opposed to a duration interval. AUDIT_EOE does not make event assembly easier, one must still cache records until the event is complete. The advantage of AUDIT_EOE is explicit knowledge the event is complete as opposed to implicit knowledge the event is complete because a duration interval elapsed. The duration interval must be time based, an interval based on the number of intervening records will fail to close the event if the audit stream becomes quiescent. But since there is no guarantee AUDIT_EOE's will be in the protocol stream one must still be prepared to close events implicitly after a duration interval. Thus the single advantage of AUDIT_EOE's is to expedite the flushing of a complete event earlier than would be possible in the absence of the AUDIT_EOE record, otherwise the complexity of event assembly is unmodified. I believe the consequences are this: 1) A real time audit parsing library must still support both event closure mechanisms (note, parsing libraries are user space and independent of kernel versions and hosts). 2) The library when it opens an audit stream must start with it's closure mechanism set to "interval". 3) If AUDIT_EOE is seen the library sets it's closure mechanism to "EOE". Closed events will then be emitted earlier than previously. -- John Dennis