Re: Assurance, permissiveness, and restriction

From: jmjonesat_private
Date: Mon Jun 04 2001 - 07:35:55 PDT

  • Next message: jmjonesat_private: "Re: Assurance, permissiveness, and restriction"

    On Sun, 3 Jun 2001, Matt Block wrote:
    
    > Crispin Cowan wrote:
    > > So here's yet another idea:  split the LSM interface into two 
    > > parts, permissive and restrictive.  Designers that want 
    > > purely restrictive functionality use only the restrictive 
    > > parts, and thus get easier/higher assurance. Those who want 
    > > permissive functionality can turn it on if they need it.
    > > 
    > > "Split" may be an over-statement.  Perhaps just a global 
    > > switch that can disable the permissive interfaces would 
    > > suffice?  Then a module designer could turn off 
    > > permissiveness, and be assured that their module will "at 
    > > least do no harm."
    > 
    > This switch should not be global, in the senses of being either
    > compile-time, or effecting all modules.  If there is any logic
    > to the "assurance" argument it remains valid if the module in
    > question simply doesn't access any of the permissiveness granting
    > hooks.
    
    This argues for splitting hooks into permissive and restrictive
    (exclusive) on the kernel side of the LSM interface, I think.
    
    > 
    > My understanding is that it is a project goal to dictate no
    > security policy but, rather, leave that to each of the modules.
    > Meddling with the ability of some module to make certain things
    > more permissive works against this goal.
    
    I agree.  So "tossing permissive completely", imho, really violates
    that requirement.
    
    > 
    > I think the multiplexor module chaining can actually solve this
    > problem; if the standard security choices were implemented in 
    > a single module, and if a multiplexor were written that allowed
    > for overriding particular hooks, it would allow all of the
    > "default" code to live in one place, and for particular modules
    > to override this on demand.  For those applications that would
    > require an override this might introduce some additional overhead,
    > but, I think it would make it even easier to modify policy and
    > customize the amount of overhead introduced (for instance, an
    > embedded application could choose to not utilize the default,
    > multiplexing module but, instead, a super-permissive "return 1"
    > module).  I have a feeling that the "default" permission set
    > and this multiplexor should be in the same module.
    
    This has been my favored solution all along.  By going with the 
    original "option #2+" pushing the logic out of the kernel to
    "somewhere" and simultaneously restoring it in a "common" place
    so some assurance/verification would be possible.  If, for example,
    that "common module" became an intrinsic part of the LSM patch, 
    and mod_reg/mod_unreg was extended to allow a "requirement" by 
    the subordinate module that it be registering with the "restrictive"
    module, modules that need a "do no worse" assurance would still have
    it, or fail to load.
    
    Can't Verify I'm Restrictive Only!  Please read INSTALL.
    
    If the "common place" is a module that can only be first-loaded, there's
    more assurance (if you allow it to stack farther down the line, the 
    interposing modules COULD "decertify" it), but if it can accept ONE 
    subordinate module registration, then you can hang a multiplexor or 
    whatever under it.  Such "families" can be established with or without
    the requirement of the "restrictive" module, so permissive/restrictive 
    or "couldn't care less about what the kernel would have said" families
    can all be implemented without much cost to anybody.
    
    But, there have been significant arguments that this dilutes the 
    open software review of the original kernel logic.  I'm not sure 
    that MUST be true, but I must admit it certainly MIGHT be true.
    
    Making DUMMY do the logic, puts it in security.h/security.c, and
    if DUMMY (um, make that STANDARD) can take one mod_reg/mod_unreg
    that can verify that STANDARD is loaded, or let register_security/
    unregister_security replace it thereafter causing mod_reg/mod_unreg 
    to fail "standard" verify, keeps it in the "after LSM" kernel tree
    where it legitimately should get "looked at."
    
    I think.
    > 
    > Or was this the discussion of this idea one of the many things
    > which has already flown over my head in this thread? :)
    > 
    >   -- Matt
    
    > 
    > --
    > Brainbench Linux MVP
    > Transcript ID# 355889
    > http://www.blockdev.net/
    
    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 : Mon Jun 04 2001 - 07:37:43 PDT