Re: Cooked audit log format

[Steve Grubb <sgrubb@redhat.com>]

On Sunday 11 May 2008 17:40:48 Matthew Booth wrote:
> I've noticed that a number of utilities cook the logs slightly. I've
> shied away from this to date because I want to be able to leverage
> existing tools. However, if some standard emerged (or has emerged and I
> missed it) for cooked logs, I'd be extremely interested in implementing
> that.
>
> Simple starters would include:
> * Translating the architecture and syscall names into human.

libauparse, ausearch, & ausyscall can do this.

> * Jumping one way or the other with the hex strings business

not sure what you mean by this. ausearch, aureport, & libauparse can handle 
them.

> * Translating socket addresses into human.

libauparse, ausearch, and aureport all do this.

> * Translating timestamps into human.

libauparse, ausearch, and aureport all do this.


> * Ditching uninteresting records, such as PATH with no name for the
> dynamic linker, and 2 PATH records when execing a script.
>
> with an ultimate goal of:
> * Defining an expected set of data for every system call and putting
> them all on a single line in a well defined format.

I have a feeling that too will become an abomination. aureport tries to get 
the audit events down to the bare essentials. But what you wind up with is 
something that makes you want more details. When you add more details you 
feel like you want less.


> Is anybody doing any work in this direction?

Not really. Part of the problem is that I occasionally hear complaints about 
the audit format, but then no one that is actually /using/ the audit output 
is willing to help define what an auditor needs. I'd really like this to come 
from people who do this as their job. 

I can take a guess at what's needed. But I really want to hear it from the 
Security Officer's perspective.

One thing that is on the TODO list is to make a output format that is like 
strace for syscall records. At least people have experience reading strace 
output and it might help make one class of record easier to understand. Doing 
this will be a big job, so I want to get some important things like remote 
logging finished before jumping into it.

-Steve