Audit Dispatcher Design

[Junji Kanemaru]

Hi,

Steve is away a couple of days so I'm responding to your mail
since I originally proposed the audit event filtering with plugins.

>>Will auditd require audisp be running or will the absence of audisp produce a
>>default behavior in auditd?
> 
> I was wondering about that too.  Is this an optional part of the audit
> subsystem or a replacement of the existing implementation?

Audisp will be running as different process, it won't hurt any current
auditd implementation. If you don't need audisp then you can just
disable it.

Audisp and auditd will be communicating thru pipes when they are
configured to use pipe. There will be networked filtering/output
plugins too.

> I was also wondering about the overall design goals, how we'd expect
> this to be used and what the performance and error handling
> characteristics would be.

It can be used many ways. For example, if you want to filter kernel
audit messages to audit some system security errors then
what you can do now is just to read logs and find message by hand.
With audisp you can filter audit messages and dispatch them.
For instance, if you want to audit:

1) AVC error messages to generate policy using audit2allow
2) Keep checking if someone's modified /var/www/htdocs/index.html

Then, with audisp, you can have filter plugins to detect them and
output where you want, i.e. output using alert box on desktop,
sending emails to admin, etc.

We are still in design phase so please let us know if you have requests
and questions.

Thanks,

-- Junji Kanemaru

CEO Linuon Inc.
Tokyo Japan