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