Re: Where Are We?

From: jmjonesat_private
Date: Wed Jun 06 2001 - 10:59:27 PDT

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

    On Wed, 6 Jun 2001, Stephen Smalley wrote:
    
    > 
    > On Wed, 6 Jun 2001, Chris Lundberg wrote:
    > 
    > > Chris (Other Chris): Move kernel logic into a default security module.
    > > Chain (or in some VERY restricted cases replace) onto that default module
    > > for everyone elses modules.
    > 
    > Could you clarify what you mean by "kernel logic"?  (Same question to
    > each person who is advocating moving the kernel logic into the modules). 
    
    At the risk of losing the advantage of vagueness, here's my definition:
    
    Any logic that is specifically in the kernel to impose security
    restrictions or permissions (capabilities or DAC, or anything else) 
    should, logically, revert to the SM in LSM.  Putting ALL security 
    into the module concentrates it in one realm, thereby 1) focussing 
    the interested eyes on that realm and 2) relieving the core kernel 
    developers from having to "think it through" by "pushing" it to the LSM.
    
    Political reasons now suggest to me that "purely" pushing this is not 
    advisable.  Practical reasons (allowing us to leverage Linux-Privs) remain 
    the same either way, imho, since if we+Linus "t'rew it all out" we could
    move the Linux-Privs project to a module, where we can also leverage it.
    
    > For example, does "kernel logic" include all >500 calls to capable(),
    > including cases where capable() is called by itself rather than
    > being in compound logic?  Or would you be satisfied simply to
    > have the compound logic statements plus the guts of the capable
    > function in the module, leaving many of the simple capable() calls
    > unchanged?  Also, what part of permission() constitutes "kernel logic"?
    > Is it just the vfs_permission logic?  What about when the file system
    > implementation defines its own permission routine for its inodes?
    > Does "kernel logic" just mean the call to inode->i_op->permission,
    > or does it mean all of the permission routines in the various 
    > filesystem implementations?
    
    
    Simply, in my mind, leave the functionality in the kernel.  Any check of 
    any kind that was there for SECURITY PURPOSES, bounce to the module.  UID
    checks, EUID checks, PID checks, CAPABILITY() checks, anything
    else. Security is not "functional" it's a decision on if the function
    should be allowed. If (forbidden || not-permitted || the-old-way) does
    nothing for functionality except limit it, the whole "permissive" thing
    is relative to the pre-existing intrinsic kernel security, and if you 
    move it ALL out, you get restrictive only (with difficulties in
    verification.)
    
    
    > 
    > --
    > Stephen D. Smalley, NAI Labs
    > ssmalleyat_private
    > 
    
    I see how the "total" argument is politically unsupportable.
    But I'd like to keep as MUCH of it as possible in the "core design" 
    of the LSM interface, leaving the implicit option later to move more and
    more and more... satisfies my philosophy AND current needs.
    
    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 - 11:01:02 PDT