Re: stackable modules

From: Crispin Cowan (crispinat_private)
Date: Wed May 23 2001 - 11:18:04 PDT

  • Next message: Chris Wright: "Re: stackable modules"

    Matt Block wrote:
    
    > For stacking modules, it seems that the multiplexor approach
    > is much cleaner and more powerful than a chaining approach.
    
    Regardless of which approach is chosen, the hard-core requirement is
    that security modules must be explicitly willing to cooperate with each
    other.  There are many security papers that describe lots of pitfalls of
    attempting to combine security policies.  It just doesn't work in
    general, so any multiple-module activity has to be coordinated some how.
    
    
    
    > It appears (from language like, "pass it down the chain")
    > that the original recommendation was for a sort of linked
    > list of modules- this, of course, will cause hell when the
    > admin decides to unload a module in the middle of the chain,
    > particularly if there is no way to pass the requirements
    > of that module around (so as to rip the appropriate stuff
    > out of the security blob).  It also offers no clear way
    > to add a module once the chain has been established.
    
    Depending on the modules in question, those kinds of administrative
    changes may not even be supported.
    
    
    > My (probably na´ve) question is, "why must the LSM be aware
    > of this at all?"
    
    Hopefully, the LSM interface, per se, will be aware of as little of it
    as possible.  The modules must be aware of each other, and not step on
    each other's toes.
    
    
    >  Not being a kernel hacker of any great
    > talent or experience, I've always sort of thought that a
    > module can do anything any other kernel code can do.
    
    That's not quite true.  The module interface defines the symbols that
    get exported to the module: these are the data and functions the module
    can conveniently access.  The module has R/W access to the entire kernel
    address space, but doesn't necessarily know the address of every kernel
    object it might want to access.  This makes "all kernel space" a
    security vulnerability for hostile modules, but not a useful paradigm
    for safe programming.  Exporting sufficient symbols is the goal of the
    LSM project.
    
    
    > It
    > may put a significant burden on the poor sod who writes the
    > multiplexor, but why would it be particularly difficult for
    > the multiplexor module to detect when another module attempts
    > to register(), add the appropriate cruft to the blob, and
    > get on with life?  Would it require the multiplexor to unregister
    > and re-register?  Would that be really really bad?
    
    It woudn't be bad.  The discussion is about the particulars of the
    stacking mechanism, the contents of the blobs, etc.
    
    
    >  Why is the sky blue?
    
    Because of the refractive index of oxygen and nitrogen ... that was a
    rhetorical question, wasn't it? :-)
    
    
    > I've also sort of always held the notion that the whole
    > point of a kernel module interface is to allow for simple
    > and quick runtime configuration of a kernel.
    
    That's one use of it.  Another is to separate code maintenance, so that
    the people who maintain the core kernel don't have to (say) know much
    about USB devices, or (in our case) elaborate security models.  There is
    utility in a kernel module that is intended to be compiled in or loaded
    at boot time, and has no capability at all to be dynamically unloaded.
    
    
    >  That is, the
    > whole idea seems to be building small (kernel-space) tools
    > for small jobs, and combining them to suit a need.
    
    Yup.  WireX has three or four modules we want to deploy.  Composing
    tools is a powerful way to get complex stuff done.
    
    
    >  Aside
    > from some small performance gain in not having to follow
    > hooks around, it's not clear to me what advantage a giant,
    > monolithic kernel module has over, say, a giant, monolithic
    > kernel.
    
    The main advantage is that Linus doesn't want to think about giant
    security modules, he wants it to be someone else's problem.
    
    
    >  That LSM hooks should support as many modules as
    > require them without too much fuss _seems_ pretty central.
    > What am I missing?
    
    Uh, nothing with respect to the big picture.  But the Devil is in the
    details.
    
    Crispin
    
    --
    Crispin Cowan, Ph.D.
    Chief Scientist, WireX Communications, Inc. http://wirex.com
    Security Hardened Linux Distribution:       http://immunix.org
    
    
    
    
    _______________________________________________
    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 May 23 2001 - 11:19:47 PDT