* Mimi Zohar (zohar@private) wrote: > >> I think it is really important to be able to share the hooks and the > >> associated > >> security data pointers in a logical and coherent fashion. For this > reason, > >> it makes > >> sense to have stacker be the hook owner and all LSM security modules > >> writing to it. > >> None of the LSM security modules, other than perhaps Stacker, should be > >> builtin, but > >> should be loaded in the initrd. > > >This makes sense iff you intend to use more than one module. For the > >cases where you don't, it's pure overhead. See the problem? > > True, but what are the options? Not providing support for sharing the > hook and data pointers, doesn't sound like a viable option. So there are > two issues: overhead and ease of coding for both with and without stacker. > To solve the ease of coding, we could define a Stacker API to access the > security field. To solve the overhead issue, we could define a compile > time option indicating whether or not to use Stacker. This option would > include a definition of the Stacker API to always return the security > field. For example, That's pretty close to what the efforts thus far are doing. thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
This archive was generated by hypermail 2.1.3 : Fri Oct 29 2004 - 09:02:31 PDT