Are the writing of an events records to audit.log atomic should a log rotation occur

Are the writing of an events records to audit.log atomic should a log rotation occur

[Burn Alting]

[-- Attachment #1.1: Type: text/plain, Size: 621 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 901 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Are the writing of an events records to audit.log atomic should a log rotation occur

[Steve Grubb]

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

Re: Are the writing of an events records to audit.log atomic should a log rotation occur

[Burn Alting]

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