Chris Wright wrote: >2. Maintain current set of hooks and push logic out of the kernel and into >the module to avoid placing hooks in compound conditionals. By the way, let me expand on why I'm concerned about this approach. Basically, it makes reasoning about correctness hard. One of the goals of Janus was to make the assurance argument very simple. The non-LSM version has a very simple assurance argument: If an operation is denied before Janus is installed, then it will for sure be denied when Janus is in place; therefore, Janus can't make security any worse than it already was. This assurance argument is very easy to verify in the non-LSM version of Janus, because the interfaces themselves don't permit 'permissive' extensions to the base security policy: one can easily see just by the interfaces (without diving into the implementation behind the interface) that Janus is a purely 'restrictive' extension. Now I know that this assurance argument is going to inevitably become harder to verify with a LSM, but if we follow option #2, things really get nasty. To verify the assurance claim, one must examine all code *and verify that it includes a proper cut-and-pasted version of the base kernel logic*. Such verification is non-trivial, and my motto is that if it is non-trivial, it is probably wrong. That's why I'm not so fond of #2. Quite possibly #2 is the best among several bad choices, and if so, so be it. Nonetheless, I wanted to list these issues in advance so that nothing is overlooked. _______________________________________________ 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 - 11:27:25 PDT