* David Wagner (dawat_private) wrote: > Stephen Smalley wrote: > >This is true, but the lack of a common header makes a lot more work for > >the multiplexor module. > > On this point, I'm not sure I agree. I wonder whether the real problem > here is that we're missing interfaces and abstractions designed for > composition. It's well-known in software engineering that if you don't > design for composition up front, it's often much harder after the fact. > > For example, I'd argue that modules should never insert themselves > by writing directly into the security_ops struct, but should call > some register_lsm() interface and pass in the desired struct setting. > Similarly, modules should never touch current->security directly, but > instead we should pass in a security field as the first argument to > each hook (much like the 'this' parameter in an object-oriented system), > or it should be available via a getsecurityblob() and setsecurityblob() > interface, or something like this. Introducing this sort of abstraction > gives us the freedom to later introduce some forms of composition. just to be clear, we do have an interface for setting the security_ops struct, register_security(). and also, the security module can register its security_ops struct with an upstream security module with mod_reg_security(). so we _do_ have _very_ lightweight support for module stacking. a primary reason we've shied away from serious support for stacking is that linus specifically said he didn't want it. so it's fair to stack, stacking is possible (not simple, but possible), and the kernel is none the wiser (which is a strict requirement at this point). the problem i have with the (get|set)securityblob is that it is now another module, and another registration that is getting closer to very explicit support for module stacking. -chris _______________________________________________ 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:05:30 PDT