jmjonesat_private wrote: > Okay, can we separate capabilities from "other" in some way, and > discuss ONLY capabilities for a moment... That's exactly what the LSM design has done: capabilities are different from the rest of the hooks: * capabilities: coarse-grained, authoritative * others: fine-grained, restrictive > I've heard (off list) some opinions that suggest that capabilities > calls should be authoritative rather than restrictive. Who ever made that comment to you needs a little chat with the Clue Stick :-) Capability hooks are not restrictive. This observation was what originally started the restrictive/permissive chat several weeks ago. > I request that we more narrowly/clearly define when permissivness is > allowable. Permissiveness: never, except in support of capabilities. "Never" is subjective: this is a community project, and everything is subject to discussion. But we've had that discussion, and current consensus is "restrictive hooks only, except for capabilities." I thought you were here for that discussion ... 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 : Sun Jul 08 2001 - 20:07:27 PDT