Application audit through auditd

Application audit through auditd

[Burn Alting]

Hi Peoples,

Has anyone had experience with using the audit libraries for application
level audit - i.e. your application log events through
audit_log_user_message() library calls?

In particular I am interested in your experiences where you have
applications generating a lot of audit records through this interface,
but at the same time, implementing, say the STIG rules along with execve
auditing. That is adding

-a exit,always -F arch=b32 -S execve -k cmds
-a exit,always -F arch=b64 -S execve -k cmds

to the stig.rules file found in either /usr/share/doc/audit-2.2 or the
contrib directory in the audit source.

Although I haven't done any testing yet, my supposition is that, on
systems that are doing a lot of execve's, then the use of the
audit_log_user_message() interface slows down the applications as they
are waiting on the netlink kernel queues.

Any comments before I start my investigations?

Regards

Burn

Re: Application audit through auditd

[Steve Grubb]

On Wednesday, June 04, 2014 09:36:15 PM Burn Alting wrote:
> Has anyone had experience with using the audit libraries for application
> level audit - i.e. your application log events through
> audit_log_user_message() library calls?

Several people lurking on this have. They may not chime in but I will give a 
few tips. If you are adding events of your own and they have nothinig to do 
with typical system operation, we have reserved the AUDIT_TRUSTED_APP record 
type for anyone to use. You can make the event into anything you want.

If however you are doing something a typical system would do, Then you should 
map the event to another user space record type and write your event exactly 
in the same format as others of the same type. Analytical programs are 
sensitive this. All fields of existing events need to be filled in in the same 
format in the same order.

If you have a new field that  a user might be able to influence, then it must 
become encoded so that a crafty user does not trick the parsers thus avoiding 
detection. If you find yourself in that situation, there is a function 
audit_encode_nv_string() that should make it easy to do.
 
Also, don't invent new names for fields. There is a comprehensive list in the 
auparse specification:

http://people.redhat.com/sgrubb/audit/audit-parse.txt

I might reorganize that document into something describing how to write well 
formed events.


> In particular I am interested in your experiences where you have
> applications generating a lot of audit records through this interface,
> but at the same time, implementing, say the STIG rules along with execve
> auditing. That is adding
> 
> -a exit,always -F arch=b32 -S execve -k cmds
> -a exit,always -F arch=b64 -S execve -k cmds
> 
> to the stig.rules file found in either /usr/share/doc/audit-2.2 or the
> contrib directory in the audit source.
> 
> Although I haven't done any testing yet, my supposition is that, on
> systems that are doing a lot of execve's, then the use of the
> audit_log_user_message() interface slows down the applications as they
> are waiting on the netlink kernel queues.
> 
> Any comments before I start my investigations?

It should not. There will be some delay in sending an event as opposed to not 
sending one. But most applications that log do some very infrequently. I have 
heard of some that send quite a bit, too. But I think you'll see a lot of 
overall delays depending on what you have for the flush setting in auditd. If 
you can tolerate the loss of events if there's an oops, then you can set it to 
"none" and just let it go.

-Steve