Re: Auditd and Watches

[Steve Grubb <sgrubb@redhat.com>]

On Thursday 24 May 2007 11:32, Simmons Jr,Felix wrote:
> >> AUDIT_WATCH_LIST: dev=104:2, path=/var/tmp/important_test,
> >> filterkey=test-file, perms=wa, valid=0
> >
> >This seems slightly odd output. What kernel and audit package are you
>> using?
>
> audit-1.0.14-1.EL4 (I know it's a little old but its what we already
> rolled out in our distro from redhat).
> As far as kernel - 2.6.9-42.0.10.Elsmp  (I'm on 64-bit architecture).

OK, I guess its been a while since I saw what came out of the RHEL4 rule 
listing.

> >Yes, I am working on a IDS/IPS system, too. But it doesn't use the
>
> logs, rather it uses the realtime interface so it can react in realtime.
> I made a
>
> >presentation about it at the Red Hat Summit a couple weeks ago and put
> > my presentation here:
>
> Thanks again, I'll give your recommendation a try.

Regarding RHEL4, the audit-1.0.15 package has the realtime interface. It does 
not have an event dispatcher yet, but it will use the one we settle on for 
RHEL5.1. In the meantime, there is a program, skeleton.c in the audit package 
that you can use to write your own event collector.

Also, the rules I gave you to exclude audit events do not work on the RHEL4 
kernel. So, writing a program to process only interesting events would be 
your best option on RHEL4 and then disregard the logs altogether.

> So I take it by reacting realtime as the event is processed by auditd and
> the event dispatcher it eliminates the potential for an event to be missed
> due to buffering or some other reason for the event not making it to the
> audit.log quick enough. 

I suppose, but there is very little memory allocating done in the audit 
daemon. What I consider the most important feature of the realtime interface 
is that it allows you to write a program to get the events as they occur and 
do something with them. You do not have to write a cron job which would be 
slow to react or do something like tail which doesn't work when the logs get 
rotated.

> Interesting, that then almost makes it so the audit.log can be rotated out a
> lot quicker and the true important events stored in the ids system.

Sure. You can also tell the audit daemon not to log anything to disk if you 
really trust the realtime path, too.

-Steve