On Tue, 14 Aug 2001, Crispin Cowan wrote: > jmjonesat_private wrote: > > > On Tue, 14 Aug 2001, Theodore Tso wrote: > > > I would suggest that what's most likely to get into the kernel is > > > something where the Linux Security Module can be made *optional*. > > > > I don't believe this is an element of the current design philosophy. Quite > > honestly, this reduces it to a combined project by several pre-existing > > projects rather than an attempt to apply security to the development of the > > Kernel. > > 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. Woids is Woids (gnyuk gnyuk gnyuk), and it's entirely possible Ted would talk to YOU differently than to an "anonymous group of unknown people". I also think that arguing LSM to the KD's is more applicable to the latter, and the "direct" conversation is more like the former. > > Ted's suggested approach has its costs and benefits. The benefits are fairly > obvious, so I won't elaborate. The costs are: > > * There is resistance to conditional code, because it makes the kernel > harder to manage & test. Confining the conditional code to header files > mitigates this issue. > * There are problems with making some of the hooks macros, because they > are used in the code as infix terms in the kernel's code body in if > () clauses. Thus the "no LSM" macros have to be carefully constructed > to be #define'd as either 1 or 0, depending on context and appropriate > defaults. > * It compromises the notion of Capabilities as a module. If you disable > LSM, you lose Capabilities entirely, so users who don't want LSM also > lose Capabilities. I.e. "no LSM" doesn't exactly return you to the > status quo kernel. > Ummmmm, would rather you have enumerated the benefits. I don't think they're as obvious as you think. 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. All three of your costs are simply eliminated by not patching the kernel with LSM at all. The "notion" of a capabilities module is the main sales point that brings me here: 1) if it's stackable, I can stack it and use it for assurance value, 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. 3) MACROS are not really necessary in the current model. All the hooks are "out negative"... by which I mean that if you don't patch the kernel at all, there's no cost. Therefore, macros are not necessary.... just make the whole ball of wax optional. Honestly, if you can eliminate all the cost by simply NOT buying into an idea, why bother? The ONLY answer to that question is "because of the BENEFIT"... we are limitting that to restrictive_only, pre-existing modules, or modules that largely provide the same functionality. > However, none of this means that LSM becomes "a combined project by several > pre-existing projects rather than an attempt to apply security to the > development of the Kernel." LSM continues to be an abstract API for building > access control modules for the Linux kernel. Ted's suggestion is just to > make the API's existance optional. That's ok, fundamental things like > network routing support is optional too. I think that it does. I respect and value SubDomain, SELinux, Janus, and the 3 or 4 other "ancestors" to my module. Because the interface is "restrictive_only" (a POLICY, no matter what the arguments to the contrary are) and enforces DAC *in-kernel*, any other strategy must either ignore LSM and pay the costs of do-nothing hooks (LSM's), or simply patch-out LSM, which, currently, is no big deal (20 seconds max.) I submit that, while LSM is addressing the current state of Linux security, it does NOT address any model or philosophy that allows future development, except coarsely and accidentally. Even where specs to the contrary are existant. > > What Ted's suggestion DOES do is raise another reason why it is infeasible to > move the existing kernel DAC logic to a module. If we do that, then it > becomes hopeless to make LSM optional, because it would break all security if > LSM is removed. Poppycock... #ifdef LSM_INSTALLED the hook #endif #ifndef LSM_INSTALLED the original code #endif 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. :) > > 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 : Tue Aug 14 2001 - 17:05:01 PDT