* Lachlan McIlroy (lachlanat_private) wrote: > > How about a scheme where a multiplexor module's version of > mod_reg_security() returns a security descriptor (like a > file descriptor) that is unique to each subordinate module > loaded and is used to access the subordinate module's > security blob with object->security[security_descriptor]? Yes, this is almost possible as it stands. The only issue is the expected return from mod_reg_security is 0 for success, non-zero for failure. This is the way we had originially discussed allowing for stacking (directly in the framework). Because arbitrary security model composition yields undefined results (oh yeah, and Linus said he didn't want to see stacking ;-) we chose to push stacking to the module -- a bit of policy to be implemented in the module not in the framework. I am not opposed to changing the mod_reg interface such that < 0 is failure and >= 0 is success. But the only way this would be useful is if the module knew to use ->security[index]. Since the common case is unstacked (direct blob access) would we expect a module to chose when to use ->security vs. ->security[index] or simply expect that a module is either stackable or not, but not both? Making all blobs void** would fix this, but this looks suspiciously like explicit encouragement in the framework for stacking. Is elaborate, flexible stacking really something people want? What's the justification (other than it's an interesting problem to solve ;-) ? thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net _______________________________________________ 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 Jul 19 2002 - 00:40:34 PDT