Re: [RFC] No more module_* hooks

From: Crispin Cowan (crispinat_private)
Date: Tue Oct 01 2002 - 00:37:53 PDT

  • Next message: Olaf Dietsche: "Re: [PATCH] accessfs v0.6 ported to 2.5.35-lsm1 - 1/2"

    Chris Wright wrote:
    
    >* Chris Wright (chrisat_private) wrote:
    >  
    >
    >>* Greg KH (gregat_private) wrote:
    >>    
    >>
    >>>Ok, that's reasonable to me, have a patch?  :)
    >>>      
    >>>
    >>Heh, not right now...I can spin up some examples later today.  Do you
    >>have an audit list of the unused hooks?  The two together would be useful.
    >>    
    >>
    >A couple of trivial examples below.  For things like iopl/ioperm where
    >capable() is only called when you are increasing your privilege level or
    >enabling perm bits on ioports I expect we'd preserve that behaviour.
    >That would mean the LSM hook would not be consulted on all checks, just
    >those deemed security sensitive.  The alternative is to hide those
    >details in the capability module, which seems wrong to me.
    >-chris
    >  
    >
    On the one hand, my instinct says that it is bad to confound the 
    permissive capable() interface with the restrictive other hook 
    interfaces: that breaks the abstraction, making the interface harder to 
    understand.
    
    On the other hand, the alternative seems even worse: the sample Chris 
    illustrates has a call to capable() followed immediately by a call to 
    security_ops->reboot(). These two hooks are now at war: the capable 
    module may be trying to permissively grant permission to reboot, with 
    some other module saying "no you cannot reboot." This is problematic 
    because from the outside (say, an admin composing modules with Stacker) 
    you cannot tell which policy will win without looking at the code.
    
    Aaieee :)
    
    So it seems to me that these two hooks should be composed, if only for 
    clear semantics. In general, we should compose adjacent calls to 
    capable/adjoining hook calls, so that it is clear who wins if the 
    policies conflict.
    
    Crispin
    
    -- 
    Crispin Cowan, Ph.D.
    Chief Scientist, WireX                      http://wirex.com/~crispin/
    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 Oct 01 2002 - 00:41:26 PDT