Audit dispatcher process

[Steve Grubb]

On Thursday 11 January 2007 14:13, James Antill wrote:
> 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. 

I'm thinking just the two that do the remote logging transfer. 

> ...even if we just stop at the remote logging plugin level, are we
> worried about duplicate entries on the logging server?

I'd rather not have them.

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

True. But we don't want to make something too complicated either. Complicated 
makes it hard to analyze for failure modes and effects.

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

Yes. The desired way to do this is SIGHUPing the audit daemon. It will inform 
the dispatcher and it will do its magic.

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

No need for this. The audit daemon has to start the dispatcher so it will have 
a pipe between the processes. There's no way to insert a plugin between the 
two without making life complicated.

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

right.

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

There should be no external libraries needed for it. Its too simple to need 
anything external. The plugins may need openssl or nss. Actually nss might be 
a better choice since its FIPS 140-2 certified. But we can talk about that 
when we get there.

> 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'd make a pointer of uint32_t type and cast it to the data's pointer. Then 
you can check its contents and decide if you know how to handle data of that 
type. Odds are it will always be in sync because its being distributed with 
the audit daemon. The note in the specification is there mostly for the 
benefit of third party dispatchers since the audit daemon could have been 
upgraded. So, in reality, I don't think you have to worry about it so much. 
Any other author will, though.

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

Yes.

> so a different config. file syntax isn't a problem, and setroubleshoot
> already has a totally different config. style.

Well, that's a whole different package, though.

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

Hmm...I hadn't wanted to pull in dependencies due to needing to do external 
code reviews. What kind of syntax needs do you think we really need? I'm open 
to ideas. The plugins I would envision might need to read their own config 
files. They might have complicated needs, but I don't think the dispatcher 
would.

-Steve