Re: Cooked audit log format
Steve Grubb wrote:
> 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.
Strings should be either always hex encoded, or always escaped
(preferably the latter).
> * Translating socket addresses into human.
libauparse, ausearch, and aureport all do this.
> * Translating timestamps into human.
libauparse, ausearch, and aureport all do this.
No doubt, but I'm interested in a general agreement around the output,
not which tools can generate it. My customer is using a third party
audit tool to collate logs from a large number of sources including
Linux accounting logs, but also including HP-UX, Solaris, Windows, AIX,
door sensors, etc... There is currently no good steer for third party
tool vendors about what log format they should support, hence I have
recommended uncooked. However, the problem with uncooked logs is that
they are offensive to the human eye ;) This makes life difficult for an
operator presented with a bunch of logs to look at, which together form
some interesting event.
> * Ditching uninteresting records, such as PATH with no name for
the
> dynamic linker, and 2 PATH records when execing a script.
Oh, also:
* Ditching CWD and making all PATH records absolute.
> 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.
The goal is semi human-readability in a standard, machine-readable
format. So include all the abominable details, but at the end of the
line ;) And put everything on 1 line. And define exactly what will be on
that line, every time.
> 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.
I don't underestimate the size of the task: it's a huge mountain of
donkey work, but it really has to be done. And maintained...
Matt
--
Matthew Booth, RHCA, RHCSS
Red Hat, Global Professional Services
M: +44 (0)7977 267231
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
Attachments:
- signature.asc (application/pgp-signature — 252 bytes)