* crispinat_private at '6/29/02 10:46 AM -0700' * * 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. How can it be critical ? The module wasn't written to support it ? As we're not using authoritative hooks we will always have built-in decisions being made. I think we need to support running older modules on newer LSM infrastructures, otherwise we're going to get into a viscious circle of version-chicken (a module wants version LSM version X, version X wants kernel Y, but I also need kernel Z (LSM version != X) because that is the only version for which feature Q is available)... Confused ? You will be after this episode.... * * Crispin * * -- * Crispin Cowan, Ph.D. * Chief Scientist, WireX Communications, Inc. http://wirex.com/~crispin/ - richard offer @ home DSS 3072/1024 0x8AFBBFA3 84 FE 48 E4 74 D0 26 D4 31 8E B6 86 98 74 E2 7C 8A FB BF A3 _____________________________http://www.whitequeen.com/users/richard/ _______________________________________________ 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 : Mon Jul 01 2002 - 15:49:28 PDT