On Tue, 3 Jul 2001, Crispin Cowan wrote: > 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. Unless I misunderstand, LSMEXAMPLE already pretty much covers this need... every hook is intercepted and a count is maintained of how many times each is called. A simple revision can reduce that to a vector as another result available to user-land. One issue (possibly not a problem) is that hooks get invoked by everything in the system, so identifying only the hooks triggered by the user-land test app might be useful in assuring it was the entity that triggered the hooks (to prevent false positives from some other source) this probably could be accomplished by filtering by PIDs or having a unique "lsmtest" GID... I'd have to check to see if that information is always available during every hook, or if there might be a cleaner way. > * 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. That would test the LSM and the Kernel, since decisions are still being made in both places. It would also be useful to know what the LSM returned from the hook to determine if the Kernel changed it or ignored it by it's logic. I could let the user-land app preset the return code (or a series of return codes) on a hook by hook basis for this purpose. Would that be useful/adequate or overkill? Perhaps just having the test module return a known errorcode not otherwise used (-ELSM) would be sufficient... if the kernel doesn't and never will react to specifically WHICH error was returned before returning to userland? I don't suspect that is the case. > > 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 :-) I can pretty easily modify the LSMEXAMPLE code to provide an LSM-TEST API that a user-land app can use, but I think the user-land app may break my bank, but if somebody wants to team up I think I can get the module-harness side done up to provide whatever info the user-land app would need. (no fame & glory necessary) > > 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 J. Melvin Jones |>------------------------------------------------------ || J. MELVIN JONES jmjonesat_private |>------------------------------------------------------ || Microcomputer Systems Consultant || Software Developer || Web Site Design, Hosting, and Administration || Network and Systems Administration |>------------------------------------------------------ || http://www.jmjones.com/ |>------------------------------------------------------ _______________________________________________ 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 Jul 04 2001 - 07:25:32 PDT