On 6 Sep 2001, David Wagner wrote: > 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. Passing the security fields explicitly in the hook call (rather than having the hook directly dereference the kernel object to set and access the security field) would address the problem, but the hooks also need pointers to the kernel objects, so it would appear redundant and greatly increase the parameters. We're not just talking about current - the same issue applies for inodes, files, sk_buffs, etc. Using functions on which a multiplexor module can interpose to set and access the security fields would also solve the problem, but imposes function call overhead on such accesses. I suppose you could use inline functions or macros, but then you would have to also recompile the individual submodules. -- 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 : Fri Sep 07 2001 - 05:01:32 PDT