jmjonesat_private wrote: > The advantages of chaining are obvious to everybody, I think. The issue for > debate is how deeply it should be allowed. Agreed. Some kind of chaining mechanism is likely to be necessary, even in state 1. > Permissiveness is a unique and complex problem... at least as HUGE as the > restrictiveness problem. Uh, no. The applicability of permissiveness is considerably more limited than restrictiveness. > > 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. That's a pretty questionable proposition, depending on what "officially realize" means. It is unclear that the mainstream kernel community will ever accept audit (I want them to, but I can't make them) and I personally am not convinced that permissive hooks should ever be a part of LSM. > 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. I am fully opposed to "recognition" that involves code compromises that serve no other purpose than to accomodate audit and permisiveness. "Leave it to later stages" means "not in this patch", because including such compromises in the code risks the acceptability of stage 1. 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 Jul 18 2001 - 00:31:30 PDT