Re: Kernel Security Extensions USENIX BOF Summary

From: jmjonesat_private
Date: Tue Jul 03 2001 - 14:31:32 PDT

  • Next message: Greg KH: "Re: attach_pathlabel"

    On Tue, 3 Jul 2001, Crispin Cowan wrote:
    
    > sarnoldat_private wrote:
    > 
    > > Yeah, it probably isn't going to be as much fun as writing the modules
    > > that we all want to write, but .. hopefully such a tool would make
    > > debugging things easier for everyone.
    > >
    > > I *did* get it correct, right?
    > 
    > Yes, Seth got it right.  The proposal was for a regression test program and
    > regression test module.  The purpose is to test whether all the appropriate
    > hooks are in all the appropriate places in the mainline kernel, so that any
    > module has the opportunity to respond appropriately.
    
    Isn't that what Chris is for? (^_^)
    
    > 
    > The threat model under consideration is kernel developers who either
    > optimize away a hook they don't understand, or add some new functionality
    > (e.g. a new way to open files) without adding appropriate hooks.  Following
    > some discussion, we concluded that there is no cure for this threat except
    > dilligence.
    
    I stand corrected.  I'm not sure there IS a cure for that particular
    threat... except diligence.
    
    There are ways I can see to exercise the hooks to determine if they're 
    in the "mix" at all.  There are ways I can see to test their responses
    against a script.  There is no provably reliable way (that I can see) to
    determine if the kernel developers add something to totally circumvent LSM
    in future releases, or modify the kernel logic to render them irrelevant 
    (retval || !retval), except a constant re-evaluation of the "other side's"
    code against our efforts, within the boundaries of LSM.  Perhaps an AI
    that reads and understands code (way, way, way, beyond me!)
    
    Quite honestly, I don't see it as something that would happen
    intentionally, but something that might be of concern if LSM and Kernel
    develop independantly.  If LSM is accepted into the kernel-proper, I think
    we would benefit from more "global" review of code changes.  Not
    necessarily OURS', but, also, THEIR'S.
    
    In the case that kernel developers "totally screw up", my "test module"
    would probably be worthless.  
    
    > 
    > Crispin
    > 
    > --
    > Crispin Cowan, Ph.D.
    > Chief Scientist, WireX Communications, Inc. http://wirex.com
    > Security Hardened Linux Distribution:       http://immunix.org
    > Available for purchase: http://wirex.com/Products/Immunix/purchase.html
    
    Sincerely,
    J. Melvin Jones
    
    |>------------------------------------------------------
    ||  J. MELVIN JONES            jmjonesat_private 
    |>------------------------------------------------------
    ||  Microcomputer Systems Consultant  
    ||  Software Developer
    ||  Web Site Design, Hosting, and Administration
    ||  Network and Systems Administration
    |>------------------------------------------------------
    ||  http://www.jmjones.com/
    |>------------------------------------------------------
    
    
    
    
    _______________________________________________
    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 : Tue Jul 03 2001 - 14:32:51 PDT