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. http://wirex.com > Security Hardened Linux Distribution: http://immunix.org > Available for purchase: http://wirex.com/Products/Immunix/purchase.html 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 |>------------------------------------------------------ || 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 : Thu Sep 06 2001 - 18:38:44 PDT