Emily Ratliff wrote: > On Tue, 3 Jul 2001 sarnoldat_private wrote: > > > The threat model under consideration is kernel developers who either > > > > optimize away a hook they don't understand, or add some new > functionality > > > (e.g. a new way to open files) without adding appropriate hooks. > Following > > > some discussion, we concluded that there is no cure for this threat > except > > > dilligence. > > Does this mean the consensus reached at the BoF was that a regression > > test program wouldn't be worth the time it takes to write one? > Yes, that was the general consensus. I'm not sure if Steve Kramer was > convinced, but the general feeling was that it was doable, but not > necessarily worth doing - it might be a good thing if hooks that weren't > > being actively used died out. Well, not exactly. The consensus reached was that a regression test suite could never be sufficient to automatically detect kernel developers disabling hooks, most especially because there is no way to detect someone adding new functionality that needs to be hooked. Thus we will need to be dilligent. That's different from saying that a tool or a test suite has no value. Sure, a testing tool would be great. Tools make it much easier to be dilligent, and therefore make it more likely :-) So, if someone wants to write a hook-presence detecting tool, that would be excellent. The basic architecture is: * A test module that contains a vector of status bits, each representing some hook that is supposed to be present. * A user-land app. that performs a bunch of operations. When these operations are all performed, presumably all of the bits in the test module will have been set by the corresponding hooks having been called. If any of the bits are not set, then some hook has been crippled. The above punts on the question of whether the kernel "responded appropriately" to the hook. A couple of varioations I can imagine are: * the "positive" case: the app tries to do a bunch of stuff, and all should succeed. * the "negative" case: the app should be denied all of its accesses. In both cases, it is the user-land app that needs to detect whether the operation was permitted or denied. Greg KH wrote: > Might want to look into the Linux Test Project: > http://ltp.sf.net > and add tests to their framework for the LSM. An excellent point. I didn't read into LTP, so my straw-man design above does not consider any factors that LTP might have raised. Anyone wanna write this beastie? There are at least 470 of us, so surely someone wants the fame & glory :-) Crispin -- Crispin Cowan, Ph.D. Chief Scientist, WireX Communications, Inc. http://wirex.com Security Hardened Linux Distribution: http://immunix.org Available for purchase: http://wirex.com/Products/Immunix/purchase.html _______________________________________________ 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 Jul 03 2001 - 16:14:28 PDT