James, Even though the xinetd model for plugins was probably a no-brainer design decision, I still agree that it's an excellent choice. Thanks for using that model. I don't know if you want to have signal (of some kind) that must be issued in order for a new plugin to take effect. Certainly, the addition of a new plugin should be an audited event, so perhaps the CAPP-suggested list automatically includes a write/execute watch on this directory.
I have a small suggestion for the local logging plugin that will probably be put in by default: * I recommend a file naming convention similar to that used under Solaris. That is <init_datetime>.<close_datetime>.<host> * <init_datetime> for 11Jan2007 at 3:46pm would be 20070111154632 * <close_datetime> is "not_terminated" when a file is currently being written, although this is doesn't work when the dispatcher dies prematurely * <host> is usually not the FQDN, but allows lots of audit trail files from lots of machines to be in one directory. * Solaris administrators issues a "audit -n" to rotate the logs when it's time, and this is occassionally quite handy when archiving logs * Real-time compression (gzip) is a GREAT idea. If the binary file written by the local logging plugin wrote whole records at a time, then a leading bit could indicate compression. Being able to turn off compression might help in high-load situations. * Also being able to set a max file size before rotation becomes mandatory makes it easy to archive audit logs to fixed-size media. A suggestion I have for the plugin architecture is to allow the plugin to query the dispatcher for internal statistics and system call number-to-name lookups. Some internal statistics might be audit buffer ring size, or other useful information to deal with high-load environments. Most everything else, the plugin can ask the OS (system date/time, system load, etc.) Is the dispatcher responsible for restarting a plugin if the process-killer targets it? A useful plugin for any authors might be a UDP transmitter, with PKE for all packets. This would allow a centralized repository in a trusted environment. Another plugin might be a real-time stream-to-tape so that audit trail retention is as easy as replacing a tape when it's ejected because it was full. By maintaining an open file descriptor at all times, other processes will have a tough time overwriting audit trails. Should anyone approach the Webmin authors once the API and directory structure is locked in so that they can write a module? Of course, I don't expect both of those to make it into the standard distro, but rather maybe spark an interest among the group. Thanks, Charlie Todd Ball Aerospace & Technologies Corp. Ctodd- at -ball.com > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of James Antill > Sent: Thursday, January 11, 2007 12:59 AM > To: linux-audit@redhat.com > Subject: Audit dispatcher process > > > Steve has asked me to write the audit dispatcher, and after > talking about it we already have some plans (as you'll see > below :) but we would welcome input from people on this list. > First to bring you all up to speed with what we know: > > > . Development should be starting soon. > > . It will, at least initially, be distributed as part of the > audit package. > > . We are planning to have a usable version for Fedora 7. > > . That initial version will be able to act as the dispatcher > for auditd and (re-)send those messages to multiple plugins. > > . Those plugins can be shipped separately. > > > ...and what seems very likely: > > > . The plugins will be external applications. > > . The dispatcher itself will not be parsing audit messages > and will be designed as a kind of Publish/Subscribe daemon. > > . In that vein, reuse of code from And-httpd/Vstr/etc.[1] is > more than very likely. > > . The dispatcher will only be doing minimal content filtering > for the plugins (this kind of falls out from the minimal parsing). > > . That message input will come from plugins, as well as the output. > > . 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"). > > . The initial set of plugins will contain at least something > to connect the dispatcher to setroubleshootd and something > for (secure) remote logging. > > > I've probably missed something already, so if there's > anything you want that isn't on the above list or anything > that isn't clear and you want to clarify ... just hit reply :). > > > [1] http://www.and.org/and-httpd/ and http://www.and.org/vstr/ > > -- > James Antill - <[EMAIL PROTECTED]> setsockopt(fd, > IPPROTO_TCP, TCP_CONGESTION, ...); setsockopt(fd, > IPPROTO_TCP, TCP_DEFER_ACCEPT, ...); setsockopt(fd, > SOL_SOCKET, SO_ATTACH_FILTER, ...); > > -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
