Re: c2 (or c2-like) auditing for Linux

chrisat_private

* Leigh Purdie (Leigh.Purdieat_private) wrote:
> Crispin / Casey, (All: For info - this may generate some useful
> discussion),
> 
> Crispin, when replying to Casey's email, said:
> > Rather, *Linus* is hostile towards audit,
> 
> I'm not sure that hostile would be the right word, but if he questions
> the usefulness of putting a large number of fairly intrusive hooks into
> the kernel, just to support auditing, he's quite right to do so! :)

Indeed.

> Despite the fact that we're running with a project that implements an
> auditing subsystem, we're certainly not under any illusions as to it's
> broad popularity ;)

Yes.  It's wildly popular in some small crowds ;-)  Of course, some of
those crowds aren't just security people.  RAS folks often effectively
push for auditing as well for the datacenter and telco environments.
This is not to say it is any more popular Linux developers and
maintainers.

> So now we're at a crossroads, and I would welcome any suggestions as to
> the best way forward.
> 
> 1) Integrate SNARE into the kernel.
>    - This is bad in some ways - particularly due to the 90%/10%
> reasoning given above. However, it does give Linux a "audit available by
> default" claim-to-fame, in order to compete against operating systems
> such as Solaris / Windows / AIX, etc - where turning on the native
> auditing subsystem is as simple as a couple of mouse clicks (or
> /etc/security/bsmconv in the case of solaris). However, it may be
> appropriate for some distributions that cater to the 'security critical'
> customers (eg: Redhat advanced server, immunix, Mandrake-security, etc.)
> 
> 2) Try and move down the LSM path
>   - Implement auditing where it's feasible, noting that we're not going
> to receive some events (eg: file open failure due to 'file not found')
> that never reach LSM.
>   - Gradually work towards adding additional LSM hooks for more
> comprehensive coverage.
> 
> 3) Pull back from the kernel side, and work with Casey and the guys at
> SGI to use their LSM backend, and provide a SNARE audit-daemon and GUI
> implementation at the front-end.

Of course, I prefer something from 2 or 3, where SNARE can use LSM
infrastructure.  Even better if you and SGI can share some common
code. ;-)

> 4) Integrate snare into major distribution kernels post-release, and
> offer alternative kernel's (source + binary) for the major
> distributions. (Note: this is a bit of a maintenance nightmare).

This does not seem far from 1, and yes, it would be a pain.  Look at the
patch sets vendors apply to their kernels.  They're very large, and easily
a cause for patching conflicts.

> 5) Some other path? (Suggestions welcome!)

Look at other things that compliment where LSM is missing audit
features.  Is there a way to leverage the work that kprobes does, for
example?  Ideally, you could manage a small patch on top of LSM, to
minimize the maintenance headache.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net
_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module