Re: Common header for security blobs

From: jmjonesat_private
Date: Thu Sep 06 2001 - 18:37:29 PDT

  • Next message: jmjonesat_private: "Module Identification, Structures"

    On Thu, 6 Sep 2001, Crispin Cowan wrote:
    > Hmmm ... if LSM is purely restrictive, and purely access control, then 
    > general composition may become feasible:
    >     * chain all the hooks: if any module says "no", then the answer is "no"
    >     * chain the blobs: each blob is actually a list of blobs, and each
    >       module walks the list of blobs looking for its own
    > This is not what we have designed, but it is conceivable, and 
    > potentially quite valuable.
    > On the other hand, going down this path really locks out authoritative 
    > hooks and anything but restrictive access control policy engines, now 
    > and forevermore.
    I'm not sure I see this point.  True, running the sequence and exiting
    with the first (or if ANY) "no" would work, but a stacking module that 
    polls 4 or 5 hooks and does some logical operation on the result (module
    (AA && AB) || (AC && AD) || AE  (AA-E being a family) is now perfectly
    reasonable.  Simply having a stacking module that runs through a table of
    subordinates and returns on the first fail works now, too.
    Note that this can be optimized to only execute the checks in a subset
    of modules to get a coherent result.
    Blob-wise, if all the allocated blobs are of the same family, the stacking
    module can identify both that and which submodule-format it's in with a
    family-specific identifier.  There does not need to be centralized support
    for this, imho, since it's confined in a module family.
    As far as chaining out hooks explicitly in the interface or anything like
    that, I just don't see the need since the stacking module can do this
    within the current paradigm, if desired, and "mixing families are BAD" has
    been a persuasive razor. 
    I guess I just don't see what sort of mechanism is being postulated, or
    how it is precluded by the current model... or how building it INTO the
    interface can help but exclude OTHER strategies.
    Restrictive or Authoritative, simple "chain order" is not really a
    technique that I see as particularly general.  What I see as useful,
    chaining-wise, is for each stage to know the result of the previous stage
    and be able to act upon it or refine it further.  After the retval has
    been passed down the chain as far as the chain-logic allows, the final
    result should drop all the way back (up) into the kernel.  I think of
    authoritative as being more supportive of this model.
    Perhaps I'm suffering from tunnel vision?
    > Is it feasible to allow some subset of LSM modules to engage in this 
    > protocol, and thus permit generic stacking of "restrictive-only access 
    > control modules"?  I don't know.  There would have to be a way for a 
    > module to declare itself to be a member of the ROACM Cabal :-) so that 
    > the stacking mechanism will let them in.  It's kind of problematic, and 
    > depends on the code details.
    > Crispin
    I think it's possible now, if the blobs being sequenced by the
    stacking/multiplexing module can be identified well enough to know if 
    they're appropriate for the "leaf" modules... which is a
    module/module-family issue, imho, not a core interface concern.
    > Crispin Cowan, Ph.D.
    > Chief Scientist, WireX Communications, Inc.
    > Security Hardened Linux Distribution:
    > Available for purchase:
    What I am I missing?
    J. Melvin Jones
    ||  J. MELVIN JONES            jmjonesat_private 
    ||  Microcomputer Systems Consultant  
    ||  Software Developer
    ||  Web Site Design, Hosting, and Administration
    ||  Network and Systems Administration
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Thu Sep 06 2001 - 18:38:44 PDT