On Wednesday, September 11, 2019 8:59:32 PM EDT Giovanni Panepinto wrote:
Thanks for the response Steve.
What exact criteria the deamon uses when it strips EOE?
Is it going to disk? If so, its stripped.
Is it purely based on the size of the event or remaining disk space
or?
That leads me to the next question, can I force it to log EOE regardless?
You can always modify the audit daemon's source code. Just remove the "if"
statement here:
https://github.com/linux-audit/audit-userspace/blob/master/src/auditd.c#L283
so that it always calls handle_event() which write it to disk. But that leads
me to the question of why would you need to do that? Is auparse not working
for you?
-Steve
> On Tuesday, September 10, 2019 11:55:58 PM EDT Giovanni
Panepinto wrote:
> > According to
> >
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/
> > 6/h
> > tml/security_guide/sec-audit_record_types , the record EOE gets
> > generated
> > to represent "the end of a multi-record event."
> >
> > In my audit logs, I can see that for some events, EOE doesn't get
> > generated.
>
> <snip>
>
> > So my question is, what defines a multi-record event? And why is EOE
> > not
> > generated when I create a file under /usr/local/bin?
>
> The EOE record is stripped by the audit daemon to save disk space. The
> audit libraries and utilities use heuristics to determine the end of an
> event. So, if you are parsing events with auparse, it will figure out
> the end of the event and group all related records for you. The EOE
> record is passes along to the real time interface just in case it helps
> to mark an event complete before the heuristics determine it is
> complete.
>
> -Steve