Re: key in syscall audit rules.
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