Re: key in syscall audit rules.
--- Klaus Weidner <klaus(a)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(a)schaufler-ca.com
__________________________________
Yahoo! Mail Mobile
Take Yahoo! Mail with you! Check email on your mobile phone.
http://mobile.yahoo.com/learn/mail