Okay, since it is sometimes useful to solve a problem from the solution back to the question, what are the real disadvantages with regard to this method: " All structures that are LSM specific should have as their first member an unsigned integer which is "reserved" for module identification purposes... however the module/family desires, but it is not required that it be used thereas. The only hook that needs carry this integer, as we've already got, is the syscall... since this may be the only function where the module identity is in question. We've got an id in security_ops, no problem other than a little reshuffling. In the other places, we'd just need to define a structure/type instead of void pointers. I *think* this would simply result in a compiler check for these structures, not any "hard function requirement." typedef LSM_BLOB... Other criteria: if the modid isn't used as identification for a module/family... it should be 0. Anybody can use anything else. That way, modules that rely on this trivial mechanism have at least THAT much assurance that they've identified "otherliness" if that value is 0. This avoids people using it as a bitmap or counter that might, eventually, match some ID string. The value of this field (the first unsigned) MUST be initialized by any module/hook that allocates an LSM structure. LSM need not check/verify/or initialize this value after any hook. " As a simple "thought experiment", how is this too costly in storage, code, or CPU time? Does it address the identification/matching need minimally? Does it impose an unacceptable policy or strategy on a module, beyond violating the NO IMPOSITION rule (that has been rather "softly" applied) previously? Sincerely, J. Melvin Jones P.S. -- I want to go on record that I'm NOT advocating this, but not arguing against it, either... just posing it as a thought experiment. If THIS strategy is too expensive in any way, any other that I can imagine is worse. I have more than enough red-ink on this list's ledger already. P.P.S. -- I'm against any composition-support rules that may be imposed by the interface... but, this is so trivial I can hardly see it as one. |>------------------------------------------------------ || 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 : Thu Sep 06 2001 - 19:21:42 PDT