key in syscall audit rules.

[Casey Schaufler]

--- Klaus Weidner <klaus at atsec.com> wrote:
> On Wed, May 18, 2005 at 05:01:50PM +0100, David
> Woodhouse wrote:
> > It doesn't actually need to be mapped by auditd
> before it hits the log.
> > Storing it as-is in the log probably makes more
> sense.
> 
> Storing only numbers makes it very hard to interpret
> older log entries;
> the mapping table can potentially change at any
> time, and there's no sane
> way to track the history of all changes to watches
> to do that. 

All unix kernel audit trails emit binary data.
Mapping to human friendly forms is left to the
analysis applications. Note however that unix
systems are not expected to change at the same
pace that Linux currently achieves. Also note
that the applications, libraries, and kernel are
maintained as a single entity, and kernel changes
that might louse up the applications are
controlled to prevent such issues.

> I don't object to storing only numbers in the kernel
> and mapping in
> userspace, but the mapping back to strings would
> need to happen before
> they end up in the log.

We've hashed the notion of intellegence in audit
daemons before, and the danger that mapping in
real time will fail remains, especially
in today's sophisticated name service environment.

Syscall numbers are something that can be
staticly mapped into strings, at the expense
of increased record size, and as it's a simple
mapping an audit daemon is not going to be
greatly impacted.

An alternative is to record the mapping in the
audit file header. This is bad if you use lots
of small audit files, but can be done in user
space once during collection and used during
interpretation. Unless you're changing system
call number dynamically, in which case I suggest
you go lie down for a bit until you feel better.


Casey Schaufler
casey at schaufler-ca.com


		
__________________________________ 
Yahoo! Mail Mobile 
Take Yahoo! Mail with you! Check email on your mobile phone. 
http://mobile.yahoo.com/learn/mail