Crispin Cowan wrote: >could we proceed with our current approach of hap hazard hook placement, but be >careful to mark each of the hooks that is permissive in nature? If all >permissive >hooks exported an interface containing the substring "permissive", then >designers >can use advanced high assurance software tools like "grep" :-) to ensure that a >module is on the safe side of the line. [...] > >Wagner proposed a full layer of indirection to manange the >permissive/restrictive. >David: can you elaborate on why the distinction needs to be dynamic, rather than >just statically designating a given hook as being permissive, and therefore more >dangerous than usual? Quite possibly I'm overlooking something important, but it seems there is a tradeoff here. If we can convince ourselves ahead of time that most hook locations will never need to support permissive policies, then your approach seems like it could work nicely. And I can't argue with enabling use of advanced software assurance tools like "grep" anywhere we possibly can! :-) On the other hand, if over time we find that there are modules who want to do permissive things essentially everywhere that there is a restrictive hook, then we could end up with sprinkling the base kernel with twice as many calls under your approach as under mine. The main reason to introduce a translation layer (in my scheme) was to expose the restrictive/permissive distinction to policy modules but to hide it from the base kernel, so that it doesn't unnecessarily clutter the base kernel code. If restrictive-only is the common case, and we only rarely need to support permissive hooks, then this consideration is certainly not an important one; on the other hand, if we need to support both in the common case, then this is where the translation layer might be worth looking at. In any case, no matter what happens, I'd be happy with your approach. Speaking personally, I only expect to use the restrictive hooks, so if we followed your approach, I'd be more than happy---probably your approach is even better for me than my own suggestion is. I just want to be fair and point out how this might affect other folks who want to implement permissive policies, even though I can't see myself falling in that camp. _______________________________________________ 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 : Fri Jun 08 2001 - 18:02:43 PDT