On Tue, Dec 14, 2004 at 04:29:52PM -0500, Stephen Smalley wrote:
> 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),
As Tim mentioned in another branch of this thread, only coarse
prefiltering for performance needs to be in the kernel, more complex
decisions can be done in userspace if needed. CAPP only requires that
filters can be set by user identity, which is trivial.
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).
Note that this kind of crash robustness goes far beyond what CAPP (and
LSPP) require, and would depend on synchronous message passing to auditd,
with the kernel waiting until auditd has synced the message to disk
before proceeding with the next step in syscall execution. I think that's
a different type of audit than the security audit records that the
current design was supposed to provide.
-Klaus