Auditing - Snare, LAuS, SELinux

[Stephen Smalley]

On Wed, 2004-09-08 at 09:22, Jonathan Abbey wrote:
> On Wed, Sep 08, 2004 at 11:33:23AM +0200, Thomas Biege wrote:
> | Enhancing Rik's framework with LAuS code is really the best choice in my 
> | opinion.
> 
> So what are the low-level advantages of Rik's framework over LAuS,
> again?  Just the low free trapping of syscalls in the non-audited
> case, and its current acceptance into the 2.6 line?

See Rik's original description of the framework in 
http://marc.theaimsgroup.com/?l=linux-kernel&m=107815879812958&w=2

By hooking the kernel internal routines such as getname and path_lookup,
Rik's framework is able to capture information such as pathnames and
device, inode pairs without resorting to any extra copying or lookups,
yielding lower overhead and less complexity (and less risk due to races
introduced by separate copying).  The tradeoff was the invasiveness of
the patch, but since the patch was accepted into the mainline kernel,
that is no longer an issue.

The framework also provided support for other components (like SELinux)
to easily generate audit messages and trigger generation of syscall
auditing on syscall exit from any point during processing, and included
support for audit generation from any calling context, including hard
irq (needed for send_sigio permission checking).

-- 
Stephen Smalley <sds at epoch.ncsc.mil>
National Security Agency