jmjonesat_private wrote: > On Tue, 14 Aug 2001, Crispin Cowan wrote: > > I disagree, but I'm cheating, 'cause I've heard Ted explain his approach to > > me in person :-) What he's talking about is to change all of the hooks to be > > macros, and put #ifdef's in header files so that the Linux kernel config can > > turn the LSM hooks into true nop's at config time, without dropping > > conditional compilation into the body of the code. > > Well, one can accept your "refocus" or not, although I'm inclined to accept it. It's not a refocus, it's an elaboration. Ted is on vacation, and took time out to write his views for us. I expanded on that, based on a verbal conversation between Pete Loscocco, Chris Wright, Ted, and I. > > Ted's suggested approach has its costs and benefits. The benefits are fairly > > obvious, so I won't elaborate. The costs are: > > Ummmmm, would rather you have enumerated the benefits. I don't think they're as > obvious as you think. Only one benefit, but it's a biggie: reduces the overhead for non-users of LSM to zero. > While there is resistance to conditional code, I would like to point out as a > "base" that applying the patch or NOT applying the patch is a "condition"... the > difference is a Y/N/M answer in make config or a download and one line of > command. Mucking with patches does not qualify as conditional code. The whole point of LSM is to make security modules loadable into standard kernels. If end-users have to apply patch files, then LSM is of no benefit. > 2) long ago, I mentioned that there was the possibility that a loadable module > might actually REDUCE security overhead by moving capabilities out or other > security functions might be accomplished with less cost than inside the kernel. > You assured me that the goal of LSM was "that and more!"... we're pretty far > from that right now. How so? If capabilities moves to a module, and you don't load it, then you've redcued overhead. I don't understand your point. > I think, in most cases, removing the in-kernel checks would require 4-5 lines, > maximum, per hook. In some cases, it would require an argument or two to the > hook. In other cases, it can't EASILY be done in one block... so it requires > documentation. > > In MANY cases, it would require some thinking. Thinking doesn't scare me. :) Requiring developers to think about how to correctly patch the Linux kernel in a hundred different places, especially with respect to security, DOES scare me. It is precisely the threat that such hacks will not be carried out correctly, everywhere, that makes the DAC-out option very dangerous. All LSM design decsions are in some sense a cost:benefit trade-off analysis. We're all learning as we go along. I expect a lot of learning to happen Wednesday evening at the LSM BOF :-) 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 : Wed Aug 15 2001 - 08:27:00 PDT