From mboxrd@z Thu Jan 1 00:00:00 1970 From: Burn Alting Subject: Are the writing of an events records to audit.log atomic should a log rotation occur Date: Sat, 02 Feb 2013 10:51:29 +1100 Message-ID: <1359762689.3612.11.camel@swtf> Reply-To: burn@swtf.dyndns.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9209456677984520703==" Return-path: Received: from mx1.redhat.com (ext-mx12.extmail.prod.ext.phx2.redhat.com [10.5.110.17]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r11NpYD9008190 for ; Fri, 1 Feb 2013 18:51:34 -0500 Received: from gateway.swtf.dyndns.org (203-219-87-38.static.tpgi.com.au [203.219.87.38]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r11NpXoa023979 for ; Fri, 1 Feb 2013 18:51:33 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by gateway.swtf.dyndns.org (Postfix) with ESMTP id 3EFAA24D005D for ; Sat, 2 Feb 2013 10:51:12 +1100 (EST) Received: from [192.168.2.100] (unknown [192.168.2.100]) by gateway.swtf.dyndns.org (Postfix) with ESMTP id 3653324D0045 for ; Sat, 2 Feb 2013 10:51:10 +1100 (EST) 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 --===============9209456677984520703== Content-Type: multipart/alternative; boundary="=-EAE6AYWgroyGutSEeJR1" --=-EAE6AYWgroyGutSEeJR1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit All, When rotating log files due a USR1 signal being sent, or for any other reason, does auditd finish writing all the records that belong to the current event being written before starting the new log file? That is, will I find records belonging to a single event in two log files? If this is the case, would there be problems if auditd was changed to wait and 'flush' all an event's records before rotating? One assumes auditd-event.c would need to be modified to be more event aware. Perhaps make use of AUDIT_EOE or other means of identifying the end of an event or a single event. Thanks in advance Burn Alting --=-EAE6AYWgroyGutSEeJR1 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit All,

When rotating log files due a USR1 signal being sent, or for any other reason, does auditd finish writing all the
records that belong to the current event being written before starting the new log file?

That is, will I find records belonging to a single event in two log files?

If this is the case, would there be problems if auditd was changed to wait and 'flush' all an event's records before
rotating? One assumes auditd-event.c would need to be modified to be more event aware. Perhaps make use of AUDIT_EOE or
other means of identifying the end of an event or a single event.

Thanks in advance

Burn Alting --=-EAE6AYWgroyGutSEeJR1-- --===============9209456677984520703== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============9209456677984520703==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Are the writing of an events records to audit.log atomic should a log rotation occur Date: Mon, 04 Feb 2013 14:32:18 -0500 Message-ID: <23054651.VinVpYuuhG@x2> References: <1359762689.3612.11.camel@swtf> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1359762689.3612.11.camel@swtf> 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, burn@swtf.dyndns.org List-Id: linux-audit@redhat.com On Saturday, February 02, 2013 10:51:29 AM Burn Alting wrote: > All, > > When rotating log files due a USR1 signal being sent, or for any other > reason, does auditd finish writing all the > records that belong to the current event being written before starting > the new log file? When it catches SIGUSR1, it sets a flag that is read by the event loop. So, this serializes it with other events. It does write the record out before rotating. > That is, will I find records belonging to a single event in two log > files? That is a different question and a different answer. Events can be composed of multiple records. It is possible for a record to be emitted and at that time a check of the disk space used or file size may cause a rotation or some other action. > If this is the case, would there be problems if auditd was changed to > wait and 'flush' all an event's records before > rotating? Auditd just writes to disk. It does not try to determine if anything is pending because its in a race to dequeue as fast as possible before buffers fill up. Any re-assembly of records into an event is done by aureport and ausearch. > One assumes auditd-event.c would need to be modified to be > more event aware. Perhaps make use of AUDIT_EOE or > other means of identifying the end of an event or a single event. It might be helpful to describe the problem this is solving. Thanks, -Steve From mboxrd@z Thu Jan 1 00:00:00 1970 From: Burn Alting Subject: Re: Are the writing of an events records to audit.log atomic should a log rotation occur Date: Tue, 05 Feb 2013 07:51:49 +1100 Message-ID: <1360011109.12259.34.camel@swtf.swtf.dyndns.org> References: <1359762689.3612.11.camel@swtf> <23054651.VinVpYuuhG@x2> Reply-To: burn@swtf.dyndns.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <23054651.VinVpYuuhG@x2> 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@redhat.com List-Id: linux-audit@redhat.com Steve, My intent is to periodically roll over the log, say every X minutes. At that point, I would run 'ausearch -i' over the newly formed file and send the output of this to a SIEM. As the SIEM maps an entire event's sed of records into one SIEM event, my concern is about the event at the start or end of the rolled over audit.log file which may not be complete (in terms of having all it's records. My thought was to change auditd to 'schedule' log rotation such that, once it receives the log rotation event, it waits till an AUDIT_EOE event (or it's equivalent) and then rotates the log file. I believe the risk of disk overflow etc due to rotation delay would be minimal, as we would only be talking about a few event records needing to be emitted before rotation (say a most a few K but on average less than 1K). If this is not a recommended solution, then I will need to make my batching process, from the first para above, state full, in that I will need to identify incomplete events and save their processing to the next cycle. Which do you recommend? Rgds Burn On Mon, 2013-02-04 at 14:32 -0500, Steve Grubb wrote: > On Saturday, February 02, 2013 10:51:29 AM Burn Alting wrote: > > All, > > > > When rotating log files due a USR1 signal being sent, or for any other > > reason, does auditd finish writing all the > > records that belong to the current event being written before starting > > the new log file? > > When it catches SIGUSR1, it sets a flag that is read by the event loop. So, > this serializes it with other events. It does write the record out before > rotating. > > > That is, will I find records belonging to a single event in two log > > files? > > That is a different question and a different answer. Events can be composed of > multiple records. It is possible for a record to be emitted and at that time a > check of the disk space used or file size may cause a rotation or some other > action. > > > If this is the case, would there be problems if auditd was changed to > > wait and 'flush' all an event's records before > > rotating? > > Auditd just writes to disk. It does not try to determine if anything is > pending because its in a race to dequeue as fast as possible before buffers fill > up. Any re-assembly of records into an event is done by aureport and ausearch. > > > One assumes auditd-event.c would need to be modified to be > > more event aware. Perhaps make use of AUDIT_EOE or > > other means of identifying the end of an event or a single event. > > It might be helpful to describe the problem this is solving. > > Thanks, > -Steve