On Thu, 31 May 2001, Chris Wright wrote: > 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). I don't think there is any real advantage of this approach over #3. > 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). On the other hand, since this is the most general solution and since it would allow even the base access control logic to easily evolve over time, this could be a selling point. Also, it seems like we are already on the path to an invasive kernel patch, since you are seeking to replace many of the existing capable() calls and they are so pervasive. But I agree that this would be a lot of work and would be risky. > 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 think I'm inclined toward this approach unless we can get a prior agreement from the Linux kernel developers that they would be willing to accept #2. -- Stephen D. Smalley, NAI Labs ssmalleyat_private _______________________________________________ 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 01 2001 - 06:10:31 PDT