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

Re: Audit Dispatcher Design



On Friday 02 September 2005 14:48, Steve Grubb wrote:
> Hello,
> 
> I am attaching an Open Office presentation that contains the slides for the 
> audit dispatcher preliminary design review. The audit dispatcher will be 
> implemented using C++ to provide some organization and abstraction for some 
> of the design elements.

Just a note:

AFAIK the OpenDocument Presentation (ODP) file format is not supported in 
OpenOffice 1.0/1.  For a list of applications that do support this file format
(including OpenOffice 2) check here,

http://en.wikipedia.org/wiki/OpenDocument#Applications_supporting_OpenDocument

> 
> The audit dispatcher will be configured by a file /etc/audisp.conf that will 
> instruct it on how to configure the input plugins and the output filter 
> plugin. Some plugins will be active - meaning that they have their own thread 
> of execution. Others will be passive and use the caller's thread.

Will auditd require audisp be running or will the absence of audisp produce a
default behavior in auditd?

> 
> The Filter plugin is a Composite of two classes - The filter and an output. 
> The filter part does the data transformation or filtering. The output plugin 
> takes the data passed to it and outputs it. The plugin class is a wrapper for 
> a shared object file that gets loaded and unloaded.
> 
> Events will be gathered by input plugins and placed into the applications 
> event queue. Filter plugins will have previously registered for callbacks for 
> new events. They will all receive the event and begin processing it. When and 
> if the event needs to be output, the filter will call its output plugin.
> 
> The audisp daemon will receive a reconfigure event whenever SIGHUP is sent to 
> the audit daemon. It will re-read its config and remove, add, or modify 
> plugins on the fly.
> 
> There are some rules regarding the implementation in C++. The ground rules 
> are: No dynamic class creation or deletion except at startup/shutdown; No 
> exceptions; and No templates.
> 
> This is a preliminary design. If there are any concerns, comments, 
> suggestions, please follow up on this. This was modeled with Umbrello - which 
> is part of Kdesdk. The PDR model will be placed on 
> people.redhat.com/~sgrubb/audit.
> 
> Thanks,
> -Steve Grubb
> 

I think it might be useful to spend 30m/1hr on the phone / IRC going over
these diagrams for all parties interested (*raises hand*).  This would be
more helpful for me, at least.

-tim


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