Re: Audit dispatcher process

[Steve Grubb <sgrubb@redhat.com>]

On Thursday 11 January 2007 00:58, James Antill wrote:
> It will, at least initially, be distributed as part of the audit
> package.

It will be distributed in the audit package as will a set of common plugins. 
Third parties can write their own just as pam modules can be distributed for 
the pam system.

> Those plugins can be shipped separately.

Well, a common set will be part of the audit system. See below.

> . The plugins will be external applications.

Yes, to be good selinux citizens, this will be necessary.

> . That message input will come from plugins, as well as the output.

The idea is that the dispatcher and plugins will be the transport mechanism 
for log aggregation. Most machines would have as sending plugin, while one 
machine would be receiving the events for logging. There is also a desire to 
be able to pull in iptables events for other plugins that would like to 
analyze these events for security purposes.

> . They'll be a mode for the plugin to run in where it speaks a
> mini-protocol with the dispatcher, instead of just getting raw messages
> from auditd.
>
> . That the mini-protocol will allow "commands" to go back to the
> dispatcher (think remote server says "out of disk space, do X" or IDS
> says "attack happening from IP block X/y, do Z").

Right. If we are doing remote logging and the remote machine runs out of disk 
space, the plugin will have to handle the admin selected action such as 
single user mode, halt, etc. I do not want a 2 way communication system with 
the audit daemon itself. This complicates its code for CAPP/LSPP analysis and 
testing. So, the receive plugin will need to ack everything its getting and 
the senders will need to wait for that ack. Also, need to consider what to do 
when reboot of the aggregator occurs. Should they spool, if so how much, etc.

> . The initial set of plugins will contain at least something to connect
> the dispatcher to setroubleshootd and something for (secure) remote
> logging.

Right, I see these as the initial common set:

1) setroubleshootd adapter to feed events to it.
2) remote logging plugin to send events to remote machine. This should use ssl 
to keep events private.
3) syslog plugin - simply takes events and writes to syslog
4) iptables event input plugin
5) remote logging receive plugin
6) possibly a filter plugin that can do matching for certain kinds of events 
and send notification when it sees that event. (not a high priority and could 
be added later depending on how long the others take.) Analogous to grep.


Other requirements:

plugin installation should be such that they are installed in a way that does 
not require editing the master config file. Perhaps each plugin is required 
to put a config file in /etc/audipsd.d directory which includes at a minimum 
path to binary and whether or not its enabled (like xinetd).

Dependencies on external libraries should be kept to a minimum and optional by 
configure options.

dispatcher interface with auditd has to conform to guidelines here:
http://people.redhat.com/sgrubb/audit/audit-rt-events.txt

config file parsing should use libaudit's parsing code. I'd like to keep a 
consistent style among pieces of the audit system.


If I think of other things I'll add them later.

Thanks,
-Steve