On 2015-01-16 05:48, Steve Grubb wrote:
On Thursday, January 15, 2015 06:20:41 PM hsultan(a)thefroid.net
wrote:
> Thanks for the info, so I tried using libauparse (again, Ubuntu
> 14.04
> LTS), however I'm hitting something truly weird: once I've adddd the
> event parsing code (taken from
>
>
https://fedorahosted.org/audit/browser/trunk/contrib/plugin/audisp-example.c
> ) and added -lauparse, what I get out of audit_get_reply now is
> mangled.
Why are you using that in an analytical program? That is a very low
level
function for getting events out of the kernel. You might want to have
a look
at this presentation to understand the audit architecture:
http://people.redhat.com/sgrubb/audit/audit_ids_2011.pdf
Auditd handles getting events from the kernel, passes them to
audispd, you
have a plugin to audispd and get the event in realtime. If you want
events on
disk, you just tell auparse_init that you want to use the logs as
your source.
Libauparse handles events after they have been processed by auditd.
I know. I sadly can't describe what I'm working on, however I have some
stringent perf requirements. That's why I've been looking at doing
custom parsing and that's why I'm bypassing the auditd daemon
completely. I figured out how to recreate a msg that auparse likes from
the output of audit_get_reply, and right now I'm planning on having both
'modes' (fast using custom parsing/ slower but 'official' parsing) live
in the binary, and simply have my process choose at start time after
parsing some specifically generated audit msgs. If my custom parsing
goes through properly, then I'll use my faster & custom parsing,
otherwise I'll revert to the official but slower parsing (and patch
appropriately to correct my custom parsing in the meantime).
Thanks,
Hassan