key in syscall audit rules.

[Klaus Weidner]

On Wed, May 18, 2005 at 01:33:28PM -0700, Casey Schaufler wrote:
> 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 agree with respect to numbers such as compile time constants in header
files.

However, the filterkey numbers we're talking about in this case are
handles for arbitrary text strings chosen by the administrator that add
labels to records matching a specific rule. The mapping can potentially
change each time audit rules are added and removed, and may even change
within the lifetime of a single audit log file.

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

In this case the mapping would be similarily simple, this would be a
simple indexed lookup in an array of string pointers.

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

Changing the system call table at run time reminds me of the old DOS way
of hooking drivers into the system, and I don't think we want to go there
again ;-)

The filterkeys can change as a consequence of administrator actions. If
you put the mapping in the audit file header, you'd need to start a new
log file after each rule change, and that would be a mess.

-Klaus