Re: Audit dispatcher process

[James Antill <jantill@redhat.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3421 bytes --]

On Thu, 2007-01-11 at 09:56 -0500, Steve Grubb wrote:

> 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.

 This is all contained in the remote plugin, or do you want a general
ACK'ing process all the way back to any input plugins. Ie.

input plugin =>
 dispatcher =>
  remote logging plugin => 
   remote server =>
    disk "ACK" => 
   remote server <=
  remote logging plugin <=
 -- stop here? --
 dispatcher <=
 -- or stop here? --
input plugin <=
 -- or even stop here? --

...even if we just stop at the remote logging plugin level, are we
worried about duplicate entries on the logging server?
 I guess that's better than missing entries if the power fails on the
logging server (I just don't want to have to solve the two generals
problem :).

> 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).

 Yeh, I'm meant to say that with the shipped separately point. One thing
I'm not sure about is if there's a requirement to pickup new
changes/plugins without having to "reboot" the dispatcher in some way.
 I'd also thought of having the auditd input be a plugin itself, this
way you could quickly reboot the dispatcher while the auditd input
plugin spooled the incoming data for a small period of time. This might
make signal handling simpler too, although it's certainly not in the
spirit of the dispatcher :).

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

 Well, if by optional you mean "something doesn't get built". Then, yeh,
I'd planned to do that ... but I'm not sure how useful it'll be, esp.
with regard to any deps needed for the dispatcher itself.

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

 Ahh thanks, I'd looked at the libaudit.h header and worked out most of
the above but the clarification is appreciated.
 One question though: Should I just take the first 4 bytes, and compare
to zero then take the next 12 ... or just grab the first 16, I figured
from the .h file that the first 16 will always be there but the above
page suggests just checking the first 32 bits (note s/32 bytes/32 bits/
to fix the typo).

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

 From what I can see of audit.conf and that code, it would be extremely
hard to use for what we'd want to do with plugins. IMO the audit daemon
and the dispatcher do very different jobs, so a different config. file
syntax isn't a problem, and setroubleshoot already has a totally
different config. style.
 The conf code from And-httpd should be very easy to reuse for this
(it's used to configure similar types of applications), already supports
conf.d directories, already supports building paths from pieces of
dynamic information etc.

-- 
James Antill <jantill@redhat.com>

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]