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. 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. 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. > > I do like how you've abstracted the interface. (especially since it has > > a similar object view to my view ;-). I'm still trying to figure out > > how we can borrow some of your work, I think it is good stuff. > > Glad you're interested. Let me know if I can be of any help. > > P.S.: Note that it is currently possible to dynamically create events > with LTT. This has interesting uses in module debugging, but could > also be quite effectively used for hook-placement testing. It's kind of off-topic for LSM, but could you comment briefly on how LTT compares to the Paradyn project at Wisconsin http://www.cs.wisc.edu/paradyn/ They have some kind of mechanism for dynamically patching binary running programs, and in this tech report http://www.cs.wisc.edu/paradyn/papers/dynopt.pdf claim to be able to do the same thing to a running Solaris kernel. Their purpose is dyanamic performance profiling -> optimization. Crispin -- Crispin Cowan, Ph.D. Chief Scientist, WireX Communications, Inc. http://wirex.com Security Hardened Linux Distribution: http://immunix.org _______________________________________________ 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 : Tue Apr 17 2001 - 06:08:56 PDT