Re: Clarifications of LSM API

From: Crispin Cowan (crispin@private)
Date: Tue Jun 29 2004 - 15:31:16 PDT

  • Next message: reuben bystrom: "Echsjxbaku Real Val1um, X.Anax, Da.Rv0n, L.Evitra..S0ma..Much M0re......"

    Tomas Olsson wrote:
    
    >James Morris wrote:
    >  
    >
    >>They are 'restrictive' in that they can only reduce access, not increase
    >>it.
    >>
    >>    
    >>
    >Is there any particular reason why LSM uses stacking?
    >
    >To me the possibiliy of having several, specialized modules called for
    >access checks in the order they were loaded, seems very useful. If one
    >denies, the operation is denied. That way, any LSMs could coexist without
    >the need for stacking implementation in every one.
    >
    >With every LSM restricting access, security wouldn't be any lower (given
    >that capable() is handled in a sensible way), right? Seems like a fairly
    >clean patch.
    >  
    >
    LSM does not "use" stacking so much as it enables stacking if you want it.
    
        * If you want to have just one big module that does all of your
          access policies, then do that.
        * If you want to compose with another module that does not want to
          compose with you, then load yours first and provide a backside
          stacking interface to your un-cooperative friend.
        * If you have a collection of modules that all do compose in the way
          you describe (reject a request if any module rejects it) then you
          can use automatic composing in the form of David Wheeler's Stacker
          module.
    
    So LSM does not so much "use" stacking as punt the issue to the modules 
    so that module implementers can choose their favorite form of security 
    policy composition.
    
    >/Tomas (please keep Cc)
    >  
    >
    Please subscribe if you want to discuss LSM :)
    
    Crispin
    
    -- 
    Crispin Cowan, Ph.D.  http://immunix.com/~crispin/
    CTO, Immunix          http://immunix.com
    



    This archive was generated by hypermail 2b30 : Wed Jun 30 2004 - 01:15:27 PDT