Re: Audit Dispatcher Design
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