On Sat, 29 Jun 2002, Crispin Cowan wrote: > This issue has little to do with module stacking. It has to do with > version control of the interface between kernels and modules. The > pathology we seek to avoid is that the kernel is upgraded to a new LSM > interface that includes new/different hooks, and someone loads an older > module. We do not want the system to result in a "failed open" state > where some critical hook is *not* mediated because the older module did > not know that hook existed. > While my interest does work toward module stacking and multiple module interaction, I agree with this evaluation. Can't a module find out what version of the operating system it's operating under? Won't LSM track the kernel on a version-per version basis? I think it can! I really think it's a service to the community to require module developers to track the kernel development... important stuff has changed nearly weekly since I've been tracking this project. Alternately, is there a way to absolutely identify the LSM interface version? I know the module can self-identify, but I'd think a new interface would have a new identifier, somehow... so modules could optionally support an older version or a newer version, potentially. Could the solution be as simple as a SINGLE *definitive* version identifier from the interface for the interface offered? Inquiringly, J. Melvin Jones > Crispin > > -- > Crispin Cowan, Ph.D. > Chief Scientist, WireX Communications, Inc. http://wirex.com/~crispin/ > Security Hardened Linux Distribution: http://immunix.org > Available for purchase: http://wirex.com/Products/Immunix/purchase.html > > *------------------------------------------------------- * J. Melvin Jones http://www.jmjones.com/ * Webmaster, System Administrator, Network Administrator * ------------------------------------------------------ _______________________________________________ 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 Jun 29 2002 - 11:31:28 PDT