Re: New LSM patch for consideration

From: jmjonesat_private
Date: Thu Jun 14 2001 - 13:35:15 PDT

  • Next message: Titus D. Winters: "Another hook"

    On Thu, 14 Jun 2001, Stephen Smalley wrote:
    
    > 
    > On Thu, 14 Jun 2001 jmjonesat_private wrote:
    > 
    > > Authoritative combines the needs of audit, permissive, and restrictive.
    > > I'd think if we move to restrictive-only we need to come up with a general
    > > solution for permissive and audit, as well, even if it largely "remains to
    > > be implemented."  This will add more potential hooks into the core-kernel, 
    > > but dramaticly clarifies the placement of hooks and their function, and 
    > > presents the *possibility* of something like a "grep" verification.
    > 
    > I think the view being taken by people who favor restrictive-only is
    > that it is sufficient to hook capable() to provide permissive support.
    > That provides a coarse-grained form of permissive behavior.  As far
    > as audit goes, we'll hopefully gain some insight from SGI as to what
    > that truly requires.
    > 
    
    I think thinking of permissive support in terms of "no more than already
    provided" is also "philosophically-"restrictive, so it would follow the
    "restrictive-only" group would want to impose that.  If "A" is a place 
    where no kernel security is supported, "B" is a place where
    DAC+Capabilities is supported, and C is a place where only
    more-restrictive (DAC+Capabilities and OTHER) policies are applied, then
    A<B<C. There are both finer grained and "otherly active" permissive
    considerations possible.  
    
    I think if we're going to be the "definitive" kernel security interface,
    then we have be "definitive". :)
    
    I'm looking forward to the insight from SGI, but am concerned it may be
    evolution along the "capabilities" line, instead of starting an "LSM line"
    solution... apologies, Casey... but I am of the opinion that providing
    permissive-only LSM-line solutions could eventually eliminate capabilities
    (as previously implemented) completely, replacing it with comparable
    functionality under the LSM module interface. (redundant, can we separate
    "LSM interface", and "LSM hooks" and "LSM module" some more usable way?)
    If I'm wrong, I'd still rather see "capabilities-line" solutions isolated
    in the interface, toward future supercession.
    
    > > If the 10 calls that were changed to add kern_retval in dummy_ are truely
    > > representative of everywhere the kernel has an opinion that we can grab,
    > > then the kernel is much less opinionated than I'd thought :), and the
    > > impact is quite minimal.
    > 
    > I only made hooks authoritative when the kernel logic was easily
    > colocated and decoupled from the functional logic.  So there are
    > many other cases where the kernel has an opinion.
    
    Okay.  But your solution does suggest how "easy" it will be.  Apparently, 
    not "very" iff there are lots of other "non-colocatable" places.  My
    following of the code doesn't find it too difficult (although, somewhat 
    difficult... especially in a few spots) or too many places where it may be
    useful-but-difficult.
    
    Did you enumerate (or count) the "not-easy" places?
    
    > 
    > --
    > Stephen D. Smalley, NAI Labs
    > ssmalleyat_private
    > 
    
    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 : Thu Jun 14 2001 - 13:36:41 PDT