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

From: Casey Schaufler (caseyat_private)
Date: Thu Jan 30 2003 - 09:22:15 PST

  • Next message: Jesse Pollard: "Re: c2 (or c2-like) auditing for Linux"

    Crispin Cowan wrote:
    
    > 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.
    
    This is a very real concern. Experiance with SecureWare, System V/MLS,
    Solaris and Irix is that the less obtrusive your audit (or any feature,
    for that matter) implementation the more likely it is to get stomped
    on by developers of other features simply because the don't know
    it's there. If the owner of the program (Linus in this case) does
    not want to have to deal with maintaining a feature it shouldn't
    go in, and efforts to minimize it's footprint are counter-productive.
    LSM is a Good Thing (tm) because it is explicitly present, and
    everyone has to deal with that, and not screw it up.
    
    > 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.
    
    Ah, good ole authoritative hooks!
     
    > 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.
    
    Yup, yes, and I agree, you betcha.
    
    
    > 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?
    
    Since C2 (CAPP in CC speak) doesn't include MAC let's
    assume B1 (LSPP). Error checks (e.g. EBADF, EINVAL) should
    be done first, and as suggested do not require audit records
    as no access control checks are done. The order of
    MAC vs. DAC checks is pretty well fixed by the MAC policy,
    in that unlike the DAC policy if you don't have MAC access
    to a file you shouldn't be able to see it's attributes
    (i.e. stat(2) should fail) so you should never be able to
    see the DAC attributes to make the DAC check in a case where
    you lack MAC access. True, the kernel code does have access,
    and in fact you need to report the DAC information in the audit
    record. You could do the DAC check first, and might still be
    compliant, but a MAC failure is much more interesting than
    a DAC failure, so you're going to have an uphill battle
    convincing an evaluation team (or a serious user, for that
    matter) that you've made the right choice just because the
    code's a little easier to get past the community.
    
    -- 
    
    Casey Schaufler				Manager, Trust Technology, SGI
    caseyat_private				voice: 650.933.1634
    casey_pat_private			Pager: 877.557.3184
    _______________________________________________
    linux-security-module mailing list
    linux-security-moduleat_private
    http://mail.wirex.com/mailman/listinfo/linux-security-module
    



    This archive was generated by hypermail 2b30 : Thu Jan 30 2003 - 09:24:37 PST