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

From: jmjonesat_private
Date: Sat Jun 02 2001 - 12:19:18 PDT

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

    On Sat, 2 Jun 2001 Valdis.Kletnieksat_private wrote:
    
    > On Fri, 01 Jun 2001 12:39:57 EDT, jmjonesat_private said:
    > > Well, "beauty is in the eye of the beholder"... my thought is it increases
    > > overhead.  If the developer of the module WANTS the kernel's advice,
    > > great... let the code in the module reproduce the original tests.  If the 
    > > strategy in place in the module would result it in "overriding" the
    > > kernel's "advice" always, why pay the cost?
    > 
    > OK.. thought experiment time - has anybody contemplated pushing *ALL*
    > and I do mean *ALL* the security/permission checking off to the LSM?
    > 
    > I mean all the places where the kernel calls suser()/capable(),
    > all the places that check user/group/world permissions, etc etc.
    > 
    > Contemplating this is a good reducto ad absurdum check for "let the
    > code in the module reproduce the tests".  Contemplate the following:
    > 
    > 1) The number of eyeballs that will look at a check for suser() in
    > mainline code, and the number of organizations that will have to
    > fix their code.  Answer:  Lots of eyeballs, and you only have to
    > fix the kernel once.
    > 
    > 2) The number of eyeballs that will look at a check for suser() in
    > a given LSM module (lots fewer eyeballs), and the number of times
    > the same problem may need to be fixed.  Yes, a blown check in a
    > given LSM may *seem* to only affect sites that use that LSM, but....
    > 
    > I've added a posting from Bugtraq from a while ago that seems to
    > indicate that we should *EXPECT* multiple people to screw up
    > multiple modules the same way.
    > 
    > /Valdis
    > ...
    
    This is a persuasive argument, undeniably.  It's also a persuasive 
    argument for not having LSM at all, but putting ALL security into 
    the Kernel... again, reducto ad absurdum.
    
    1) Since all the security would be in the virgin kernel, more eyes
       would see it, review it, argue it, fix it.
    
    2) There'd be no chance of duplicated errors, since the code would 
       be the code would be the code.
    
    Whenever you introduce "options", you divide the audience into
    subaudiences with differing objectives for evaluating the 
    implementation.  Since you have fewer people in "each camp", you 
    have fewer people looking at each solution.  
    
    LSM provides options.  It's going to divide.  SELinux people will 
    focus on SELinux solutions, IMMUNIX on immunix solutions,
    ACME-BUDGET-SECURITY on ACME-BUDGET-SECURITY solutions.
    
    
    Moving the logic from the kernel to the module need not necessarily 
    divide the peer-review/verification.  A possible solution might be
    a common source library say, "standard_security.h" that *can* be 
    #included for every module and contains macros for each moved
    check, and is commonly reviewed by the community at large.  The 
    same macros could be used in the "NO LSM SUPPORT" kernel, an LSM 
    that wishes "same support", or not at all in an LSM that goes another
    direction.
    
    The addition of chaining/stacking opens other opportunities for 
    a "commonly reviewable resource", in the same fashion that the 
    current "standard capability_plug" module needs to be reviewed 
    to assure it exactly reproduces the original kernel logic.  Without a 
    chaining/stacking mechanism, EVERY module must independantly 
    verify their code, rather than hooking in a verified capability_plug 
    with some common assurance.
    
    Since verification must be done in any case, centralizing as much 
    of what needs to be verified in ONE place makes sense.  Having it 
    potentially scattered all through the kernel and also in the LSM
    just makes it more difficult.  By moving it ALL out of the kernel, 
    into a common "access point", it can be done.  This approach may 
    be easier with option #2, since #3 will leave more in the virgin 
    kernel that can (and probably will) be changed in the future.
    
    Move it ALL out of the kernel, with a shared set of tools that all module 
    designers *optionally* may be able to incorporate if it fits their 
    strategy, and you have "one place" for both LSM and Kernel
    developers to look to fix and verify.
    
    In My Humble Opinion, Of Course,
    Sincerely,
    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 : Sat Jun 02 2001 - 12:20:50 PDT