Near Term Audit Road Map

[Steve Grubb]

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