Re: Kernel Security Extensions USENIX BOF Summary

From: Crispin Cowan (crispinat_private)
Date: Tue Jul 03 2001 - 16:12:43 PDT

  • Next message: David Wagner: "Re: pathnames"

    Emily Ratliff wrote:
    
    > On Tue, 3 Jul 2001 sarnoldat_private wrote:
    > > > 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.
    > > Does this mean the consensus reached at the BoF was that a regression
    > > test program wouldn't be worth the time it takes to write one?
    > Yes, that was the general consensus. I'm not sure if Steve Kramer was
    > convinced, but the general feeling was that it was doable, but not
    > necessarily worth doing - it might be a good thing if hooks that weren't
    >
    > being actively used died out.
    
    Well, not exactly.  The consensus reached was that a regression test suite
    could never be sufficient to automatically detect kernel developers
    disabling hooks, most especially because there is no way to detect someone
    adding new functionality that needs to be hooked.  Thus we will need to be
    dilligent.
    
    That's different from saying that a tool or a test suite has no value.
    Sure, a testing tool would be great.  Tools make it much easier to be
    dilligent, and therefore make it more likely :-)
    
    So, if someone wants to write a hook-presence detecting tool, that would
    be excellent.  The basic architecture is:
    
       * A test module that contains a vector of status bits, each
         representing some hook that is supposed to be present.
       * A user-land app. that performs a bunch of operations.  When these
         operations are all performed, presumably all of the bits in the test
         module will have been set by the corresponding hooks having been
         called.  If any of the bits are not set, then some hook has been
         crippled.
    
    The above punts on the question of whether the kernel "responded
    appropriately" to the hook.  A couple of varioations I can imagine are:
    
       * the "positive" case:  the app tries to do a bunch of stuff, and all
         should succeed.
       * the "negative" case:  the app should be denied all of its accesses.
    
    In both cases, it is the user-land app that needs to detect whether the
    operation was permitted or denied.
    
    Greg KH wrote:
    
    > Might want to look into the Linux Test Project:
    >         http://ltp.sf.net
    > and add tests to their framework for the LSM.
    
    An excellent point.  I didn't read into LTP, so my straw-man design above
    does not consider any factors that LTP might have raised.
    
    Anyone wanna write this beastie?  There are at least 470 of us, so surely
    someone wants the fame & glory :-)
    
    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
    
    
    _______________________________________________
    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 - 16:14:28 PDT