Re: content and format?

["John Calcote" <jcalcote@novell.com>]

[-- Attachment #1: Type: text/plain, Size: 2524 bytes --]

Steve,

Sorry it took so long to get back to you on this note. I was out of town for a week and then took Christmas break and tried to stay away from work during this time. :). 

This looks good Steve. I can't wait to see more details as you make them available. I can't see immediately how this parser library will work, but I'm sure that with the information you'll be providing in the next few months I can make them work together so my team can provide/access all of the benefits of laf in our project.

I'll follow the list and keep you posted on what we're doing - just FYI.

--john

-----
John Calcote (jcalcote@novell.com)
Sr. Software Engineeer
Novell, Inc.


>>> Steve Grubb <sgrubb@redhat.com> 12/14/06 11:25 AM >>>
On Thursday 14 December 2006 12:24, John Calcote wrote:
> So what's in the future for linux audit regarding content and format?

I think we should be in position to allow reformatting of audit information on 
the fly early next year. I think the key to doing this as well as creating 
many new tools will hinge on the audit parsing library.

This library has been spec'ed out and designed with higher level languages in 
mind. http://people.redhat.com/sgrubb/audit/audit-parse.txt The first problem 
that anyone runs into if they want to make tools is how to parse the events. 
This library will let you get past having to study all the messages to create 
parsing rules.

The audit daemon has been created with a realtime interface so that other 
analytical programs can get their hands on the data in near realtime. This 
offers a lot of advantages over cron based techniques that read from a file. 
The realtime interface lets the daemon itself be simple so that it can pass a 
CAPP/LSPP eval and yet offer expansion capabilities.

The plan to allow other formats, reactive programs, or centralized logging is 
to create a dispatcher that reads the output of the daemon and hands the data 
to programs that have subscribed to it. Right now, we have a primitive 
dispatcher to test the concept out with SE Linux where a program analyzes 
events and offers help to users if they see a pattern that would suggest a 
boolean needs to be changed.

There is another dispatcher that is close to what I am thinking of:
http://www.linuon.com/dowloads/led/ 

Anyways, what we can do is have a plugin that takes audit events and uses the 
parser library to extract the fields its needs for a message and then write 
it to disk or send it across the network.

John, would this scheme work for you?

-Steve

[-- Attachment #2: John Calcote.vcf --]
[-- Type: text/plain, Size: 410 bytes --]

BEGIN:VCARD
VERSION:2.1
X-GWTYPE:USER
FN:John Calcote
TEL;WORK:1-801-861-7517
ORG:;Unified Identity System Eng TE
TEL;PREF;FAX:801/861-2292
EMAIL;WORK;PREF;NGW:JCALCOTE@novell.com
N:Calcote;John;;Sr. Software Engineer
TITLE:Sr. Software Engineer
ADR;DOM;WORK;PARCEL;POSTAL:;PRV-H-511;;Provo
LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:John Calcote=0A=
PRV-H-511=0A=
Provo
END:VCARD


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