Audit Dispatcher Design

[Steve Grubb]

On Thursday 08 September 2005 19:02, Linda Knippers wrote:
> Would the default behavior be that the audisp isn't used, so the auditd
> writes the records to disk the way is does today?

Probably not. But that's how you would configure it for CAPP.

> Is it the case where one chooses between the current behavior or sending
> everything to the dispatcher? 

No, you now have 4 choices: no logging but eat meassages, auditd logging, 
audisp logging, or both audisp & auditd.

> Or is there a case where auditd still writes to the audit log but also sends
> the records to the pipe? 

Yes. This would be the likely case.

> > No performance goal. There is a queue between auditd & audisp to decouple
> > the rate of processing.
>
> Would you worry about flow control?  Pipes can back up so would you log
> something if you're dropping messages between the two daemons?

I was planning to make the pipe action configurable so that you can have 
either "best effort" or "try harder". Best effort would be used for local 
logging since you don't really care as much about anything else. If you 
disable local logging, then audisp could be blocking writes since its now 
more important.

> Will the audit dispatcher be usable with the data moving around so much?

Sure.

> Or could it actually be better because you could be reducing the data along
> the way and writing less to disk?

Not sure.

> That's why I  was wondering what the real objective is.

There's lots of people wanting to get their hands on events in realtime to 
react to something. That's what its all about.

-Steve