On 1 Jun 2001, David Wagner wrote: > 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. Not to be confrontational, at all, but could you define your usage of "correctness" for me? I suspect I might argue, but our definitions are probably very different. > > 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. Um, in a general sense... "can't make anything worse" might not be the policy of the module in place. The policy MIGHT be willing to make specific things "worse" for one reason or another, such as if the system is really a honeypot. > > 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. > Admitted. > 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. All code must be "verified to comply" only in the "more restrictive starting from the 'kernel base' code" case. A certain kernel-based check may be totally eliminated, because it's covered by "check A and check Y" totally (more and less restrictive), or a module may be implemented with a less restrictive philosophy, or even a more restrictive policy based on TOTALLY DIFFERENT checks, for a variety of reasons. If it's your project's intention to be "base+", admittedly, a difficulty is introduced for Janus, but "starting below base and moving in a different direction" would not necessarily introduce a problem for any other project. > > 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. > Very reasonable, but #2 opens up vistas of possibilities that may NOT be what Janus systems are looking for, without imposing the "verification" cost from the kernel checks and allowing flexability. To be applicable, the security needs of the system must match the security resources provided by the module. It seems you're arguing for imposing your "bottom line" with the LSM interface: which is "above all, allow no WORSE security by maintaining the ORIGINAL and adding on." Playing Devil's Advocate, J. Melvin Jones |>------------------------------------------------------ || J. MELVIN JONES jmjonesat_private |>------------------------------------------------------ || Microcomputer Systems Consultant || Software Developer || Web Site Design, Hosting, and Administration || Network and Systems Administration |>------------------------------------------------------ || http://www.jmjones.com/ |>------------------------------------------------------ _______________________________________________ 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 - 12:04:44 PDT