Re: Dispatcher - single line output (perl)

[Steve Grubb <sgrubb@redhat.com>]

On Monday 22 May 2006 08:35, Leigh Purdie wrote:
>From what I understand, supporting this feature in the kernel is a
> little challenging due to the potential memory/cache requirements -
> having to save off the 'pieces' of an event from initiation to exit,
> could be quite expensive when we're talking in-kernel resources.

This is pretty much what the audit system does in the kernel. It saves 
everything in the context until it decides to output an event. Then it dumps 
all records associated with the event into the netlink queue.

> Hence, we're left with an audit output that could:
> * Have an arbitrary number of lines per unique event,
> * Be chronologically distributed in some cases (event lines may be
> spread over several seconds),

Doubtful.

> * Be out of sequence (numerically - two lines from event A, might be
> followed by 1 line from event B, then another line from event A,
> followed by the rest of event B).

I haven't seen this except when we introduced a bug in the kernel.

>  * Have multiple 'items' with the same name (eg: source/dest UID's for
> a CHMOD have the same 'name/key', though they are on different lines).
> (Please let me know if these assumptions are incorrect!)

The record type has something to do with the meaning of any items.

> However, the dispatcher infrastructure offers the potential to
> implement this sort of functionality in user-space.

Yes, I'm glad to see more people use this feature. Please note that there is 
an API version number that dictates the format of the records passed through 
the event dispatcher mechanism. Right now, the version is 0. It is the 1st 32 
bit word sent in the dispatcher header. I should probably add a specification 
to my people page so that everyone knows the rules. 

Also, the audit daemon can be told not to log anything locally so that its all 
done across the network. Its in the auditd.conf man page. The dispatcher is 
responsible for adding the machine or host's name if that's needed in the 
record.

> We also getpwname/getgrname (with an internal cache to avoid recursive
> audit events), and an internal simple realpath() to turn
> /path/to/blah/../../to/somewhere into /path/to/somewhere.

Not looking at your code...but you probably are referring to munging CWD & 
PATH records to create complete path? If not, that's what you need to do.

> The raw perl is attached. Does anyone have any comments, or
> suggestions? 

Just one, at some point I'm going to pick up work again on the audispd 
program. It will have a plugin architecture that will allow multiple programs 
like yours to share the event data. Its likely to be a couple months before I 
start back into it...but I just wanted you to be aware of the long range 
plans.

But until then, its fine to grab the event dispatcher hook and use it 
exclusively.

> In particular, comments would be welcome on how to absolutely,
> programatically determine when an 'event' is complete, and it is safe
> to push out our final 'line'.

When the serial number changes is what I've been using in ausearch/aureport. 
The events should all be out within a second. When it decides to dump the 
records for a single event, it all happens quickly.

-Steve