On Sat, Apr 21, 2001 at 01:38:43AM +0000, David Wagner wrote: > Greg KH wrote: > >Not hard, consider the following code: > > lock_kernel(); > > security_ops = &dummy_security_ops; > > unlock_kernel(); > > That looks great as an *implementation*, but let me suggest that this > code be hidden behind a register_hook() / unregister_hook() interface. > In particular, I think it would be a good idea to ensure that policy > modules don't go modify the security_ops structure theirselves, but > go through some API -- this way the implementation of what's behind > the API can change to accomodate, e.g., locking or loading multiple > poilcy modules. > > What do you think? Do you agree? I agree about hiding the registration and unregistering behind a function call that handles it. I did just that in the patch I posted. As for hiding access to the security_ops structure itself? That's a much tricker thing to do. Remember the LSM lives in kernel space along with the rest of the kernel, so it can touch any part of kernel memory that it wants to, even if we "hide" it. Also any thing that implements this would cause the way to call the hooks to slow down. thanks, greg k-h _______________________________________________ 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 : Sat Apr 21 2001 - 09:58:56 PDT