Crispin Cowan wrote: >So here's yet another idea: split the LSM interface into two parts, permissive >and restrictive. Designers that want purely restrictive functionality use only >the restrictive parts, and thus get easier/higher assurance. Those who want >permissive functionality can turn it on if they need it. In this context, a proposal I made earlier might be relevant. I hope noone will mind if I repeat myself a little bit. Introduce a translation layer. The base kernel logic will still contain calls to security_ops->hook(), and this will resolve to the translation layer. LSM's can register permissive_hook(), a restrictive_hook(), or both with the translation layer. The translation layer can then be in charge of registering a security_ops->hook() with the base kernel to ensure that the relevant LSM *_hook()s get called. This might provide a clean way to support both easy-to-verify restrictive-only modules as well as more general (but possibly harder to verify) modules. The above, by the way, is just an example, and the details should not be taken too seriously. The main point is that adding a translation layer allows a lot of freedom. If this general approach is to be followed, there should still be some discussion on the details. For instance, what are the semantics when a restrictive_hook() says 'deny' and a permissive_hook() says 'allow'? Possibly it is better to have a restrictive_hook() and an override_hook(), where the latter always takes precedence and allows fully general policies, intended to be used only where restrictive_hook() is insufficient. _______________________________________________ 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 : Sun Jun 03 2001 - 14:49:37 PDT