I just wanted to summarize the current proposals for building a consisitent hook interface that solves the needs of restrictive modules (arguably most) and permissive modules (i.e. capabilities). I think we can agree on the need to provide a way for modules to express either restrictive or permissive policies. Following are three alternatives that have been suggested with my comments added. 1. Add separate hooks to explicitly allow both permissive and restrictive policies. this allows for flexibility at the expense of simplicity in the interface (as well as the kernel code since we'd be adding the hooks). 2. Maintain current set of hooks and push logic out of the kernel and into the module to avoid placing hooks in compound conditionals. this allows for flexibility at the expense of rebuilding kernel logic in the module. really calls for stacking modules. looks like an invasive kernel patch (may be a hard sell). 3. Maintain current set of hooks and keep logic in the kernel. Add an argument to hooks to show whether the kernel was going allow or deny the action. this allows for flexibility, but i'm not sure it builds a consistent interface. hooks that we've added beyond capabilities are not always in conjunction with kernel restriction tests. guess we can always pass in "kernel would've allowed this" in those cases to build consistency. i guess i prefer the approach in option 2, but perhaps option 3 is more likely to be accepted in to the kernel. thoughts from the list? other options? -chris _______________________________________________ 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 : Thu May 31 2001 - 18:14:24 PDT