Re: Application audit through auditd
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