[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Audit Dispatcher Design

Steve Grubb wrote:
> On Wednesday 07 September 2005 17:57, Linda Knippers wrote:
>>I was also wondering about the overall design goals, how we'd expect this to
>>be used  
> That was stated here:
> https://www.redhat.com/archives/linux-audit/2005-August/msg00073.html

Sorry, I completely forgot about the first message by the time I read
the second. :-(

Would the default behavior be that the audisp isn't used, so the auditd
writes the records to disk the way is does today?  Is it the case where
one chooses between the current behavior or sending everything to the
dispatcher?  Or is there a case where auditd still writes to the audit
log but also sends the records to the pipe?

>>and what the performance and error handling characteristics would be.
> 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?

> What can you say about error handling other than it must be correct? auditd is 
> not going away. It will be the method for reliable logging. 

If that's the case (I wasn't sure before) then I'm less worried although
I'd still be concerned about backups between auditd and audisp impacting
the reliable logging, and also the overall performance impact on the
system.  Will the audit dispatcher be usable with the data moving
around so much?  Or could it actually be better because you could be
reducing the data along the way and writing less to disk?  That's why I
was wondering what the real objective is.

> audisp is going 
> to be best effort at this point. For example, if you use remote logging 
> should the machine stop if the network goes down? Should it queue them and 
> transfer when the network is up? What if the queue fills to capacity? If the 
> remote logger's disk is full, should all machines on the network go to admin 
> mode? That'll be a bummer. I don't think we want to face all these issues and 
> claim 100% guarantee at this point.

There's probably no one right answer.  Looks like a couple of knobs
for each type of plugin.

-- ljk

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]