Re: best way to audit in vfs
On Tue, 2004-12-14 at 16:23, Klaus Weidner wrote:
I think this is the fundamental disagreement here - if you want to
filter
audit records based on object identity, you need to have the object
identity information available when applying the filter rules. If you
want to do the filtering in the kernel, there isn't really any
alternative to storing this information in kernel space.
If you can determine within the hook function itself whether or not you
need to emit an audit record, then it can make that determination (based
on object identity, current process information, particular hook, etc)
in isolation, and you don't need to save any state temporarily. You can
just immediately have the hook function emit an audit record with the
information available to it, and that automatically enables generation
of an audit record upon syscall exit that includes the syscall number,
return code, args, pathname info, etc. That is what SELinux does today.
I think the linked-list approach mentioned may be appropriate,
keeping
only the information needed for in-kernel filter decisions in directly
accessible arguments. Any other audit information could be stored in the
list and then delivered to userspace in bulk on syscall exit.
While that is possible (and necessary if you truly need complex audit
policies based on more than what one hook can decide), it does mean that
you don't get any audit notification until operation completion (and
possibly none at all in the event of a crash), which might be
undesirable if the auditable object was detected very early in
processing the operation (or if the operation itself produced the crash
_after_ an audit determination could have already been made).
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency