Re: Assurance, permissiveness, and restriction

From: Stephen Smalley (sdsat_private)
Date: Mon Jun 04 2001 - 11:13:07 PDT

  • Next message: Stephen Smalley: "Re: sys_setpriority error"

    On Mon, 4 Jun 2001, Titus D. Winters wrote:
    
    > I still maintain that the way to go here is to push it all into the module
    > and make the default module contain the current kernel logic.
    > 
    > The points I would like to make are:
    > 
    > 1. Political difficulties should not be considered in the design of
    > software.  Anyone that says otherwise is trying to avoid a flamewar.
    > Personally, I'd rather fight the flamewar battle personally and let
    > someone else do the development if that's what it takes to get it done
    > right the first time.
    
    I don't understand this argument.  I don't mind flamewars, but LSM
    is worthless to us if it is not accepted into the Linux kernel.  So
    we have to consider how acceptable our solution will be to the Linux
    kernel developers.
    
    We also need to limit our scope or we will never get anything done.
    Many of the participants in LSM only need a set of hooks to be
    added that allow them to enforce additional access control restrictions.
    The capabilities logic can be moved out of the kernel simply by
    changing the guts of the capable() function and the capability 
    processing in execve and the capability system calls to call
    hooks.  That also allows other modules to implement permissive
    behavior in the same way as capabilities (Someday, it would be nice
    to have finer-grained permissive behavior, e.g. process in domain
    D can override discretionary read restrictions on files with type
    T, as in DTOS, but that isn't on the critical path). We
    don't really need to change the existing capable() calls - we can simply
    insert new hooks calls where needed.  Auditing can be supported through
    appropriate post- hooks.
    
    Where's the real argument for moving all of the base logic out of
    the kernel?  Identify exactly what project needs it, and why it
    can't be supported adequately through separate hooks (including
    the capable hook for permissive behavior).
    
    I can't see us devoting resources to such a significant effort when
    it doesn't provide any benefits for our security modules and it
    doesn't help our case to the Linux kernel developers.
    
    
    --
    Stephen D. Smalley, NAI Labs
    ssmalleyat_private
    
    
    
    
    
    
    _______________________________________________
    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 Jun 04 2001 - 11:15:30 PDT