Re: Hooks, authority, MAC, the future and proposol

From: Crispin Cowan (crispinat_private)
Date: Mon Jul 09 2001 - 01:01:23 PDT

  • Next message: Amon Ott: "Re: Kernel Security Extensions USENIX BOF Summary"

    LA Walsh wrote:
    
    > So if we are going for stage I.  We'd propose:
    >
    > 1) That the project adopt new prototypes for some of the existing security
    > calls to support the argument collection requirements of a future audit
    > implementation. Reason: We don't want to force an API change once the it has
    > been accepted into the kernel.
    
    Module API changes are permitted mid-stream.  While it is prudent to add
    arguments sooner than later, it is also prudent to keep the patch small for
    Stage I.  A necessary precondition for these additional arguments, providing the
    data should be cheap, and the additional source code patches should be light.
    
    
    > 2) move to authoritative hooks with the standard security moved into a module
    > that is compiled in and completely compatible with the current security (bug
    > for bug, feature for feature).  I know this topic was discussed last month,
    > but we couldn't give input at that time.
    
    As Wagner said, consensus was to stay with restrictive hooks, both for the
    receptivity with the kernel community, and for the "safety" property.
    
    Similarly, broad consensus was to leave the classic UNIX security logic in the
    kernel, and not try to modularize it.  My main concern is that the classic
    security checks are tightly interwoven with other, non-security kernel logic,
    and that means that moving the security logic to a module is bug-prone.  I don't
    believe that such a task could be accomplished bug-free on the first try.  IIRC,
    most of the LSM community concurred. Discussion with Ted confirmed that he feels
    the same way.
    
    So basically, based on past consensus:
    
       * Question 1 (additional arguments):  maybe, depending.
       * Question 2a (authoritative hooks):  most of us would rather not.
       * Question 2b (moving kernel security logic to a module):  no way, unless you
         have something to say that's likely to change the consensus of both the
         LSM community and the kernel community.  So far, I personally am not
         swayed.
    
    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 : Mon Jul 09 2001 - 01:02:36 PDT