[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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 epoch ncsc mil>
National Security Agency


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]