Re: Near Term Audit Road Map
On Friday 27 February 2009 11:13:44 am LC Bruzenak wrote:
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.
Couple questions:
Do you see that pulling in the dispatching will cause more auditd complexity
or is that not a problem?
The current chain is:
kernel->auditd->audispd->audisp-prelude
What it would become is
kernel->auditd->audisp-prelude
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.
Sort of. It was mostly to do the demultiplexing, but in reality, people windup
getting queue overflows between auditd and audispd.
- 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.
The problem is auditd gets backed up trying to send to audispd. Audispd rarely
gets backed up and when it does you can increase the queue. But you can't do
this between the audit daemon and dispatcher. Then auditd backs up the kernel
queue.
- What do you see as the initial target platform for the 2.0 series
in
Fedora?
Either 11 or 12 depending on when I can get it done and pushed through.
In RH I assume it would be the next RH release thereafter?
Yes, it would aimed at RHEL6, with the 1.8 series becoming RHEL5 only.
-Steve