On Thu, 6 Sep 2001, Chris Wright wrote: > something needs to coallate the modules' decisions and generate an > aggreagrate result. This is true, but the lack of a common header makes a lot more work for the multiplexor module. As I said earlier, without a common header, the multiplexor module must save the original security field on entry to the hook, and then set the field to point to each module's object before calling each module's hook. Same thing in reverse on allocation of the objects. The problem is that the modules directly dereference the kernel object's security field to set and access it, so they are all looking in the same place. If we have a common header, then each module can simply be written to search the list in the header for its own object, identified by the module id. Likewise, each module can be written to insert a new blob into the list when alloc_security is called. This simplifies the multiplexor module to merely calling the submodules in sequence on the kernel objects, without needing to tweak the security field at all. > and if we add the magic number and list, we'd need to initialize them in a > generic fashion before calling the module's alloc_security() wouldn't we? No. That would be up to the individual modules. -- Stephen D. Smalley, NAI Labs ssmalleyat_private _______________________________________________ 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 - 13:14:36 PDT