jmjonesat_private wrote: > Very reasonable. Although I can not envision a means of moving in-kernel > checks OUT without pre-requiring authoritative hooks. Neither can I, but since DAC-out is not likely to happen, I don't care very much. > I suggest this: > > 1) make hooks authoritative, Not yet. I'm still waiting to hear whether the promised advantages are real or not. In particular, I want to know whether Smalley's style of authoritative hooks (DAC-in, DAC-first, send DAC result to module as a parameter, and let the module make the final decision) actually improves SGI's situation. Richard? > 2) DON'T buy-in the DAC-OUT yet, but keep an open mind, Sorry, my mind is close on this issue :-) > 3) CREATE, approve, review, whatever, a stackable module that enforces > hooks as restrictive_only, to address the obvious need. It's really > not even minimally difficult. Sure, if #1 actually goes through. 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 : Mon Aug 06 2001 - 10:48:29 PDT