> 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.

Hello, LC Bruzenak píše v Po 12. 05. 2008 v 10:50 -0500: > Q: Will the (hopefully) soon-to-be released visualization tool have any > influence on this discussion? > Regardless, my original question was would more cooking find its way > into the visualization tool? And any idea of when that may be released? A preliminary version will be easily installable in a few days; you can download a tarball from https://fedorahosted.org/audit-viewer right now, but building the required python-gtkextra bindings requires some effort.[1]

Q: Will the (hopefully) soon-to-be released visualization tool have any influence on this discussion? Also aggregation?

It should also be a goal that correct parsing of audit logs not be dependent on specific kernel versions.

> Strings should be either always hex encoded, or always escaped > (preferably the latter). The issue that always dominates any thinking about the audit system is how to save diskspace. So, whenever a string has no naughty characters, we let it go as is. If the string contains something that will confuse the parser or do other bad things, we encode the string such that the parser cannot be confused. But we only do that on demand because the majority of strings are well-behaved.

On Thursday 15 May 2008 06:28:15 Tony Jones wrote: > On Mon, May 12, 2008 at 11:19:46AM -0400, Steve Grubb wrote: >>> Strings should be either always hex encoded, or always escaped >>> (preferably the latter). >> The issue that always dominates any thinking about the audit system is >> how to save diskspace. So, whenever a string has no naughty characters, >> we let it go as is. If the string contains something that will confuse >> the parser or do other bad things, we encode the string such that the >> parser cannot be confused. But we only do that on demand because the >> majority of strings are well-behaved. > Are you talking here about the escaping that is performed inside of auditd? > If so, IMO, this seriously needs to be reworked. The way it works (encoding > the entire string rather than just escapinng the offending characters) > doesn't make sense plus it's very inefficient in terms of implementation. I > mentioned this to you in private mail at the time of the buffer overflow > advisory. I'm happy to work on a patch but it's always possible I'm missing > some design subtlety ;-) Before sending a patch, it has to be backwards compatible. IOW, there is no guarantee that someone will update user space tools and run an old kernel or use a new kernel with old tools. There's no way to enforce this and people will expect their tools to work. Also note that the hex string encoding is used to encode some data structures, so you would need to be judicious in which fields use whatever encoding. About the scheduling of such a patch, I wouldn't want to merge the patch until the remote logging is complete. (Its the last scheduled feature of the current development series.) After that point, I think we are at the branching point for big changes again.