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

From: Crispin Cowan (crispinat_private)
Date: Wed Jan 29 2003 - 22:55:03 PST

  • Next message: Crispin Cowan: "Re: Sample"

    Chris Wright wrote:
    >* Seth Arnold (sarnoldat_private) wrote:
    >>On Wed, Jan 29, 2003 at 10:34:30PM -0500, Valdis.Kletnieksat_private wrote:
    >>>We recently had a rework of the LSM code such that it added zero executable
    >>>unless you asked for LSM in the .config.  Would Linus be more receptive
    >>>if audit was similarly implemented?
    >>Performance isn't everything. I've heard a bit of reluctance on the
    >>part of kernel maintainers for the existing LSM hooks; adding dozens of
    >>new hooks for auditing purposes is a significant amount of new source,
    >>even if none of it ever makes it to the standard user's compiled kernel.
    >I agree.  It's not just runtime overhead that's a concern, but also
    >source code maintainability.
    I also agree. In fact, I suspect that the ugly mess that all the 
    audit-motivated hooks would create in the current architecture would be 
    the prime motivator for rejection, not the performance issue. Who really 
    cares how slow the error path is?
    To constructively answer Valdis' question: I think what it would take to 
    get full audit into LSM would be acceptance among Linus et al for the 
    proposal known here in 2001 as "DAC Out", i.e. move *all* of the DAC 
    (Discretionary Access Control) logic out of the kernel and into an LSM 
    module. This is radical surgery to the Linux kernel, and would entail:
        * some massive re-factoring of a lot of kernel logic
        * *full* support for stacking, because now nearly all kernels will
          have to stack whatever special LSM modules on top of the nearly
          ubiquitous DAC module
    In it's favor, I think that some of the LSM nay-sayers in LKML might 
    regard this design as less of a kludge than the current LSM.
    BIG caveat: this is a massive undertaking. It is definitely *not* viable 
    for Linux 2.6. It should only be considered for proposing to whatever 
    comes beyond 2.6. I submit that it will need enough political buy-in 
    that we should solicit input from other subsystem communities, such as 
    the file system, extended attribute, and in-kernel crypto people.
    Question for Casey & other Orange Book folk: the above proposal 
    *assumes* that it is C2 compliant to do checks in this order:
       1. error checks (no audit records if they fail)
       2. DAC checks (audit records)
       3. MAC checks (audit records)
    Does this assumption hold?
    Crispin Cowan, Ph.D.
    Chief Scientist, WireX            
    Security Hardened Linux Distribution:
    Available for purchase:
    			    Just say ".Nyet"

    _______________________________________________ linux-security-module mailing list linux-security-moduleat_private

    This archive was generated by hypermail 2b30 : Wed Jan 29 2003 - 22:56:36 PST