5:51 p.m.
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
1:32 p.m.
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
2:51 p.m.
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
4338
days inactive
4341
days old
linux-audit@lists.linux-audit.osci.io
2 comments
2 participants
participants (2)
-
Burn Alting -
Steve Grubb