Re: Audit dispatcher process
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