On Tue, Apr 17, 2001 at 06:06:30AM -0700, Crispin Cowan wrote: > Karim Yaghmour wrote: > > > Interesting analysis. I agree with your appreciation of the positionning > > of the hooks. Some retrieve interesting information regarding the occurrence > > of an event, but are too far from the critical decision making to be useable > > for a security module hook. This is an argument for what I suggested > > previously, a broad range of pre-defined hooks that could be selected > > at compile-time. I suspect that there could be different degrees of > > hooking. Hence, a basic security module may need a very little number > > of hooks, whereas an extended security module may necessitate deeper > > hooks. This too could be made configurable. > > That breaks the "loadable module" part of LSM. It is a goal that all LSM > modules compiled for (say) Linux 2.6.3 should be loadable into all Linux 2.6.3 > kernels. So if you get the latest Red Hat or SuSE CD, and then you go get your > favorite module, it should just load into the standard binary kernel that you > have. No, Linux does not support a binary module API and this project isn't going to add that. You will still have to recompile your LSM module for each disto's kernel to get the exact same match of compiler version and kernel options to work properly. > If you require that the kernel be re-compiled to make a module work, then it's > not really a module, it's a source code kernel patch. That's a valid approach, > but not what we're trying to do. No, the kernel will have to be recompiled. Your description of a module is incorrect with regards to Linux kernel modules. > So if we're to avoid requiring users to say "make config; make dep" etc., then > all of the hooks that every LSM needs will have to be compiled in by default. > "LSM Support" will likely be a compile time option, just as "LKM support" is a > compile time option today. They will have to rebuild the LSM module to match the kernel they are using if you have a LSM that does not ship with the kernel. Now the 2.5 kbuild process will enable modules that live outside of the kernel to built easier. Remember Linux has a source module API, not a binary one. So Karim's original proposal is a valid one. Not one I necessarily agree with, but it does not break any module interface structure like you insinuated. greg k-h -- greg@(kroah|wirex).com http://immunix.org/~greg _______________________________________________ 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 : Wed Apr 18 2001 - 16:06:59 PDT