ABI guarantee for auditd

[hsultan at thefroid.net]

On 2015-01-16 05:48, Steve Grubb wrote:
> On Thursday, January 15, 2015 06:20:41 PM hsultan at 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