David Wagner wrote: > 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. I have great fondness for this assurance argument. We used the same argument in SubDomain. This assurance argument is actually the primary motivator behind my suggestion of "kick capabilities right out of LSM", and it's up to Linus whether it stays in the mainline kernel, or goes all the way to the bit bucket. > 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. To preserve the assurance argument for LSM, I would very much like it if LSM provided purely restrictive hooks. Stephen Smalley pointed out that I overstated myself: Capabilities is not purely permissive, it is a mix. However, I conjecture that Capabilities is the ONLY permissive module on the table. Can anyone dispute this claim? Got an example of some other module that wants to be permissive? Crispin -- Crispin Cowan, Ph.D. Chief Scientist, WireX Communications, Inc. http://wirex.com Security Hardened Linux Distribution: http://immunix.org Available for purchase: http://wirex.com//Products/Immunix/purchase.html _______________________________________________ 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:03:27 PDT