On Fri, 13 Jul 2001, Crispin Cowan wrote: > > modules). These goals point to an expanded effort along the lines of > > JMJs chaining, but also to an abundance of hooks admitting of > > permissiveness as well as restriction. The advantages of chaining are obvious to everybody, I think. The issue for debate is how deeply it should be allowed. Permissiveness is a unique and complex problem... at least as HUGE as the restrictiveness problem. I'm not sure how narrowly the needs could be defined by referring to 'pre-LSM' literature, but time marches on and ideas here may be the "classic literature of the future." > > LSM is a very *practical* project. It is *entirely* about enabling > existing security technologies that work to be easily deployed on standard > kernels. Security research into interesting ideas is easy enough to do: go > get a Linux source tree, and hack it up to your heart's content. But only > when said research is done, the new security model has been shown to be > effective, you want to make it widely deployable, and you can convince a > large number of people not only that what you do can't be done with > LSM as-is, but that the beneifts out-weigh the costs, would it be > appropriate to add new things to LSM. People who "soup up" cars are practical, too. Likewise, PRACTICAL means you understand that, say, a wheel bearing will need to function through stresses and under conditions that have never before seen. So, you build things as flexible and tough as possible and then EXPECT it to fail..., and expect to learn more things from that failure. Imagine you're an engineer who is building a bridge. You only take into account what's been done before. You don't set the "X-factor" coefficient high enough in your design. You end up with the old Tacoma Narrows bridge... very practical and cost effective, but if the wind (crackers) blows to hard, you end up with bridge pieces in the river. :) > > IMHO, the priority sequence for LSM is: > > 1. Finish the current rendition of LSM and get it into the 2.5 kernel (as > Greg said) > 2. Audit > 3. Permissive hooks I agree 100% with this. I argue that: if we can see that far ahead, let's build the interface to accomodate 2 and 3 without significant modification so modules can *trust* the API for a while, and know that... if we haven't changed the hook, the function will behave as expected. > In any case, I feel much more strongly that "finish stage 1" is high > priority than I do about disputing which of audit or permissiveness is more > important. So lets go finish stage 1, and then worry about the other > stuff. Only one minor exception: lets *officially* REALIZE audit and permissive hooks are coming and allow for them in the code. A "dangling" pointer or two costs very little, but provides a place coders can hang a function for test and evaluation without abandoning the interfacce. Otherwise, 90% YES. :) > 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 Jul 17 2001 - 14:30:37 PDT