Near Term Audit Road Map

[LC Bruzenak]

On Fri, 2009-02-27 at 10:33 -0500, Steve Grubb wrote:
> 
> During the work for a 2.2 release, I would also like to pull the
> audispd program inside auditd. In the past, I tried to keep auditd
> lean and single purpose, but with adding remote logging and kerberos
> support, we already have something that is hard to analyze. So, to
> improve performance and decrease system load, the audit daemon will
> also do event dispatching.
> 
> Would this proposal impact anyone in a Bad Way?

Steve,

Couple questions:
- Right now the audispd remote/prelude plugins have connection-related
concerns. For example, with the remote plugin there are timeouts,
retries, etc. and parameters to tweak that. With the prelude plugin, it
must have been registered with the running prelude-manager correctly or
it dies. Do you see that pulling in the dispatching will cause more
auditd complexity or is that not a problem? I thought that (one reason)
audispd was separate was to allow it to deal with the vagaries of
endpoint and delivery issues while the auditd kept doing its thing.

- In theory, if everything is still doing roughly the same amount of
work, I'd think that moving the functionality would not necessarily
decrease the system load. I'm sure you have thoughts on how this would
be realized and at some point I'd be interested to hear those.

- What do you see as the initial target platform for the 2.0 series in
Fedora? In RH I assume it would be the next RH release thereafter?

Overall, though, I'd vote that nothing you propose would harm my
efforts, since I think I'd be stuck with the 1.8 series for a while
anyway.

Thx,
LCB.

-- 
LC (Lenny) Bruzenak
lenny at magitekltd.com