Crispin Cowan wrote: >Hmmm ... if LSM is purely restrictive, and purely access control, then >general composition may become feasible: Yup, glad you agree. That's what I was trying to argue. (And I suspect this example of taking the intersection of two restrictive-only policies is one interesting example of a special case we can handle, but maybe not the only such.) > * chain the blobs: each blob is actually a list of blobs, and each > module walks the list of blobs looking for its own Yup. You can probably clean this up a bit, too. If you replace use of current->security in each base module by some appropriate abstraction, a multiplexor can call both modules in succession (and respond to that abstract interface appropriately). The benefit of this is that the base modules don't need to know much about stacking, so long as they satisfy the requirements (e.g., that they are restrictive-only). >On the other hand, going down this path really locks out authoritative >hooks and anything but restrictive access control policy engines, now >and forevermore. Hmm. I must admit I don't see why. What it does is ensures that you can only use this type of stacking with restrictively-only modules. Does it mean that SubDomain has to implement a restrictively-only policy? No, it doesn't. If SubDomain uses a restrictive-only policy, then it can be stacked in this way; if it doesn't, it can't be stacked in this way. These are tradeoffs, but the module designer is free to choose which approach to follow. As I see it, this doesn't narrow our options; rather, it expands them. >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. Why problematic? For instance: Add a flag to the register_lsm_module() interface, so that the module declares whether it is restrictive-only or not. It's up to the module developer to know which class his module falls into. You can lie to register_lsm_module(), but if you do, you deserve what you get. _______________________________________________ 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 : Fri Sep 07 2001 - 10:24:39 PDT