Audit dispatcher process

[Todd, Charles]

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: linux-audit-bounces at redhat.com 
> [mailto:linux-audit-bounces at redhat.com] On Behalf Of James Antill
> Sent: Thursday, January 11, 2007 12:59 AM
> To: linux-audit at 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 - <james.antill at redhat.com> setsockopt(fd, 
> IPPROTO_TCP, TCP_CONGESTION, ...); setsockopt(fd, 
> IPPROTO_TCP, TCP_DEFER_ACCEPT, ...); setsockopt(fd, 
> SOL_SOCKET,  SO_ATTACH_FILTER, ...);
> 
>