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 -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
