Re: Where Are We?

From: Chris Lundberg (clundberat_private)
Date: Wed Jun 06 2001 - 10:50:35 PDT

  • Next message: Stephen Smalley: "Re: Where Are We?"

    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).
    > 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?
    
    Oi!  That is a bunch of stuff to think about...  My basic stance, from a
    theoretical, nonimplementational point of view is that all of the logic in
    the kernel should be able to be overridden completely, and that the
    cleanest way to do it in the long run is have the kernel take care of the
    work, whereas the security modules should take care of _all_ of the
    questions as to whether or not it is allowed.  Thus, I believe that all
    capability(), permission(), etc operations should be called by security
    hooks.  I further believe that the logic (as it exists now) should be
    transformed into a module or set of modules that are commonly
    present/chained and are known to work together.  From there, our security
    modules can chain off of that list to override those decisions.  My
    reasons:
    
    1) From what I understand, there are some folks out there that want LESS
    security (not less restrictive, so much as flat out less checking) whereas
    others (us, in general) want more security (again, not so much more
    restrictive as more complex and robust).  It would be cool if we could
    meet both groups' requests.  I believe that including all security
    (including user permissions, uids, cap(), perm(), etc) as a module or set
    of modules will allow both groups to achieve this goal.  Caveat: I do not,
    at present, have a good plan for implementing these modules, only that I
    would like them implemented.
    
    2) It will make the kernel clean, in general.  There will be one call to a
    series of chained functions.  It will be obvious what that call does.  It
    eventually returns whether or not to execute the functionality, and if
    not, why not.
    
    3) It will make module development relatively clean.  All modules must
    then use chaining, which is a minor nuisance, but by no means impossible
    to enact.  The modules then must make their decision based on the error,
    or lack of an error, passed by the previous module.
    
    4) It wil make the modules robust.  Modules will be able to be permissive,
    or restrictive, or both.  Another caveat: chaining has its own development
    problems, which are unfortunate artifacts of not being able to compose
    arbitrary functions.  Chain order will always be important.  We'll have to
    deal with that if we use chaining.
    
    5) It will make more sense.  All of the calls to any type of security
    restriction or permission are in security, not scattered about the kernel.
    There will be hooks scattered around, but that is far cleaner than the (as
    you mentioned) 500+ calls to capable.  I'm all for compartmentalizing
    things.  Put security in security where it belongs.
    
    Of course, this plan of action is not an easy, quick fix, and will require
    that a lot of convincing be done to ensure that we are eventually
    accepted, but I believe it is the correct way.
    
    Chris Lundberg
    Harvey Mudd College
    
    
    _______________________________________________
    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 - 10:51:38 PDT