Near Term Audit Road Map

[Matthew Booth]

Steve Grubb wrote:
> Hi,
> 
> With the proposals sent to the list, I wanted to talk about how this might 
> play out code-wise. With regard to the current code base, I am working on a 
> 1.8 release. This would represent finishing the remote logging app and 
> nothing more. The 1.8 series would become just an update series just like the 
> 1.0.x series did.
> 
> In parallel with finishing remote logging, I would release a 2.0 version. 
> Patches applied to 1.8 would also be applied to 2.0. A 2.1 release would 
> signify the completion of remote logging that branch. I would recommend this 
> branch for all distributions pulling new code in. 
> 
> The 2.0 branch will also have a couple more changes. I want to split up the 
> audit source code a little bit. I want to drop the system-config-audit code 
> and let it become standalone package updated and distributed separately. 
> 
> I also want to drop all audispd-plugins in the 2.0 branch and have them 
> released separately. They cause unnecessary build dependencies for the audit 
> package.
> 
> 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?

On the contrary. My austream tool was born because:

* Ensuring a dispatcher doesn't generate audit events is fragile
* The additional task switching and memory copying becomes onerous under
load

Additionally, auditd is clearly geared up for writing to disk: certainly
in RHEL 4, switching off all disk related activity is a whole lot of
typing to tell it not to do anything :)

Solaris's BSM implements custom behaviour with loadable modules. If our
auditd did that, hopefully I could deprecate austream. The dispatcher
architecture doesn't lend itself to sustained high volume.

Matt
-- 
Matthew Booth, RHCA, RHCSS
Red Hat, Global Professional Services

M:       +44 (0)7977 267231
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490