From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Cooked audit log format Date: Mon, 12 May 2008 10:43:17 -0400 Message-ID: <200805121043.17906.sgrubb@redhat.com> References: <482767E0.10506@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <482767E0.10506@redhat.com> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com List-Id: linux-audit@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