Plugin framework

[Steve Grubb]

Hi,

Its time to start the ball rolling with the new development. First up is the 
plugin architecture. Let me explain a proposal and then we can discuss it.

To make the audit system more useful, we need to be able to pass events to 
other software for realtime analysis and responding. We also need to be able 
pass protection profiles which mean the audit system cannot be complicated to 
explain its operation. We also cannot allow plugins to the audit system to 
corrupt or crash the audit daemon.

The way that this will be accomplished is to add another configuration 
parameter dispatcher. This will take the full path to a program that 
dispatches audit events. The audit daemon will fork on startup and open a 
pipe.

The dispatcher will read from stdin to get audit events. The audit daemon will 
use nonblocking writes to the pipe so that it can move on to process the 
event itself. (We could make it configurable as to whether to use blocking or 
nonblocking writes.) If the dispatcher parameter is empty, the audit daemon 
will behave as it currently does. The dispatcher that is standard with the 
audit package will be /sbin/audisp. By having the dispatcher specified as a 
parameter, third parties can write their own.

The proposed architecture looks something like this: 


                [fd1]   [fd2]   [fd3]
                   I1       I2     I3
                        \      |      /
                      event queue
                         /     |     \                        
                       F1   F2    F3
                       |       |       |
                      O1   O2     O3


The different items along the top are input plugins. The audit daemon is one 
of them. The user may have other sources of data that they want fed to the 
dispatcher. Maybe IPTables events for example.

These events get queued where different filters examine the event. The filter 
picks off the event, processes it and sends it to an output plugin. The 
output plugin could be used to send the event out of the machine to an 
aggregator. It might be arranged something like this:


              C1           C2           C3
                 \            |             /
                     NETWORK
                              |
                  I1         I2
                    \         |
                      event queue
                         /     |     \                        
                       F1   F2    F3
                       |       |       |
                      O1   O2     O3  


C1 - C3 are the output plugins from different computers. They come into a 
listener plugin on the monitor computer. The monitor computer is running the 
same audisp program and handles the other computer's events in its own queue.

This also lends itself to remote logging instead of alarm or IDS. The new 
audit daemon will also have a new format option NONE, that tells it not to 
log the events to disk. This means it depends on audisp as the transport 
mechanism.

Now some specs going forward. What I would like to see is a framework that any 
number of plugins can be developed for. There should be:

PLUGINS
input plugins - These gather events and send them to event dispatcher.

filter plugins - these perform reduction of data. They may be used for either 
input or output chains. For example, event dispatcher sends all events to 
filter. The user may be using a plugin that filters all but AVC denial 
messages. Only avc denial messages are output. The filter plugins can also 
transform data. For example, maybe the user want the data changed to xml, or 
python, or java friendly data. Perhaps they want some fields removed.

output plugins - These are assigned to filter plugin and write the data 
received from its input. There can be a number of these. One for console, ssl 
socket, af_unix socket, syslog, dbus, append to file, send email, or execute 
a program passing the data.

CONFIGURATION
The config file should let the user specify a chain of plugins that input 
events. The config file should let the user specify the chain of plugins for 
output. The order in which data moves is specified by the chain. It is 
unclear how to specify configuration information for the plugins. Maybe the 
command line. For example, the relay is going to need to have a destination 
address & port. The filter plugins may need a list of fields to pass or list 
of fields to suppress.

THREADING
Threading - multiple threads may be used. They must be detached. They should 
have cancellation points. It is unclear if the user should be able to specify 
thread pool size. 

TERMINATION
auditd must be able to send sigterm and have all threads shutdown.

RECONFIGURE
The audit daemon shall send a message type AUDIT_DAEMON_RECONFIG which will 
cause audisp to re-read the configuration.


At this point we should open the discussion and determine what plugins we 
would like to have. I can create the list if no one any requests.

-Steve