On Mon, 4 Jun 2001, Titus D. Winters wrote: > I still maintain that the way to go here is to push it all into the module > and make the default module contain the current kernel logic. I agree, but not necessarily entirely on the same points. > > The points I would like to make are: > > 1. Political difficulties should not be considered in the design of > software. Anyone that says otherwise is trying to avoid a flamewar. > Personally, I'd rather fight the flamewar battle personally and let > someone else do the development if that's what it takes to get it done > right the first time. > Political difficulties, unfortunately, can only be discounted completely in a "theoretical world." Some thought and analysis has to be paid. To some extent, though, we're "second guessing" what our problems will be before deciding what we're selling. Each of us has a different level of "paranoia" (um, it ain't paranoia if they really ARE out to get you.) Down that road lies "pay the fine to avoid the trial", thereby maximizing our downside risk. Trying to test our "philosophy" against the "prevailing" philosophy, though, has some merit, so we "proceed in the most likely to succeed way." And learning from history helps too. I don't want to have an LSM interface that discounts, prohibits, or fails to provide a clearcut forward path to implementation for any major "branch" of thinking that's been stated here, if possible. Therefore, I want to have "the most general purpose solution" possible. The fulcrum the world will tilt on, though, is how well we fit into the "Linux way of development", and there is some pressure on us to "tip" toward being as minimalist as possible then building on that later. I strongly resist tipping too far, is all. I *STILL* see option #2 (pushing SOME of the logic off to the module) and recapturing that logic in the default "module" in security.h/security.c default module code, coupled with a mechanism to totally replace that logic if desired, within the module, or for the module to *preserve* it, optionally, is the optimal solution. With that agreed, the argument then drops to "how little we can move out to the module without prohibitting any of our forward paths without going back to rework the interface", to address the "political" concerns. > 2. Condensing all of the default hook logic into security.c / security.h > does _not_ reduce the number of eyeballs looking at it, it just moves > everything important (to us security geeks) into one place so that we can > actually find the things that we are looking for in the (woefully > underdocumented) kernel source. With this, I agree. In fact, I think it may give the "more interested" eyeballs a chance to focus on the "needles" in the kernel code "haystack" more directly. > > -Titus > 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 : Mon Jun 04 2001 - 12:37:38 PDT