Re: permissive vs. restrictive issue and solutions...

From: jmjonesat_private
Date: Wed Jun 06 2001 - 06:16:20 PDT

  • Next message: jmjonesat_private: "Re: permissive vs. restrictive issue and solutions..."

    On Wed, 6 Jun 2001, Stephen Smalley wrote: 
    
    > 
    > > That's true, as far as it goes, but it prohibits anybody from wanting
    > > that from using it, and forces any who DON'T, to accept it.
    > 
    > I don't follow your argument.  Let's say that my module only wants
    > to implement restrictive behavior on permission().  So, 
    > the module's permission hook function might look like:
    > 
    
    <snip>  I concede that your example will allow either permissive or
    restrictive, and is very compact.  
    
    My objection is that, in any case, your solution requires the kernel
    logic to be evaluated before the module is called, and requires a 
    hook by hook decision as to if it may be relevant enough to include 
    the argument in the list.  This creates the following situation:
    
    1) Module designs that totally ignore the original kernel logic must
       still wait for it to be resolved, discarding the result.
    
    2) A consensus must be reached in the design of the interface to 
       add "kern_retval" to each hook that "may" need it.  While we're 
       all one big happy family ;), I suspect that different security 
       module designs will need it in different places.  Requiring a 
       central decision on where to add it instead of a mechanism that 
       allows individual modules to "choose" if kern_retval is significant, 
       (and, therefore, if it needs be calculated,) not only puts us in a 
       perpetual argument for "add this", but forces those that don't 
       need it to pay (the computational cost) for it.
    
    3) If you move the kern_retval check to AFTER the module, by the 
       request of the module, it is possible that some of what is 
       checked (such as euid) *may* be altered by the module before
       the evaluation is done, allowing the module some influence 
       in the result.  Yes, you could duplicate the check in the module
       with a value changed, but now you're doing the check twice.
    
    
    I think your solution is very viable, I only disagree with a few
    of the minor "implications" thereof.  I am wondering if a slightly
    less compact solution might not be worth the "muss" for the added
    flexability.
    
    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 : Wed Jun 06 2001 - 06:17:31 PDT