[PATCH] Add End of Event record

[Steve Grubb]

On Thursday 27 September 2007 13:18:35 Todd, Charles wrote:
> 1. A (pseudo-)RFC describing the dispatcher "protocol"

What do you need to know? Plugins read from stdin, they must obey SIGHUP and 
SIGTERM, they must keep stdin empty. They can be sent either string data or a 
pseudo binary format straight from the audit daemon (I do not recommend that 
for anyone). The string format follows the guidelines laid out for the audit 
parser library.


> 2. A rigid, easily parsed record format - AUDIT_EOE might keep it easy
> on the reporting subsystem

That is defined in the audit parsing library specs (although it needs updating 
for the node field). As for EOE, I had planned to filter that out when 
writing to disk as it just wastes disk space. The real issue is that for 
realtime reactive systems, every second counts. This lets them start to take 
actions faster. For reporting, all events are on disk and the EOE can be 
deduced.


> 3. Administrative records are passed, perhaps at dispatchers startup and
> at the start of a file when rotated, that documents which version of
> auditd, uname -r, output of gnu_get_libc_version(), and the local system
> date/time.

The auditd version is already recorded. uname -r output might be nice to add. 
I don't see why glibc version is needed. It has nothing to do with audit 
rules or events (the kernel does, though). Local system time is already 
recorded in every record.


> The administrative record, when mentioning auditd's version, may even
> indicate a "backward compatible to version..." so that 1.2.6 might still
> be able to parse 1.2.12, but as of 1.3 the format changed so backwards
> compatability is broken.

This is unnecessary since the audit daemon takes the event and writes it 
straight to disk. The audit format should not be changing from name=value in 
the foreseeable future.

The nice thing is that if anyone wants to do something new, you can write a 
plugin to disassemble the native event and re-write it into any format you 
want.


> My goal is this: 3 years from now, an employee is being investigated.
> The investigator makes me pull up all the raw records from my network
> and analyze them.  Now I've interpreted user names, group names,

names and groups are the one thing that needs to be thought about.


> syscalls, 

libaudit has a full table


> and hostnames during capture (ausearch -i),  

hostnames are another thing to think about, but shouldn't be as troublesome as 
users and groups.


> but if the format changed through the years, I need to have analysis tools
> be aware of the format.  This gets back to a previous posting I did
> on "Offline audit trail analysis."

-Steve