Chris Wright wrote: >* jmjonesat_private (jmjonesat_private) wrote: >> security_ops->capabilities >> security_ops->restrictive >> security_ops->permissive >> security_ops->audit > >You still have not convinced me that there is an value in splitting the >restrictive and permissive hooks apart like this. I am strongly in >favor of a single hook with authoritative control. Here's my take on it. I don't see the value of exposing security_ops->{permit,restrict,...}->hook to the base kernel. However, if modules want to separate these different types of hooks (and I think there are some benefits to many modules to be able to express this), then there is a way that this can be supported transparently, without exposing the existence of multiple types of hooks to the base kernel. Here's how. The base kernel sees a single security_ops->hook, which points to an optional translation layer (think of it as a special type of module that just does multiplexing). The underlying policy module can register its own favorite type of hook -- lsm->permissive_hook(), lsm->restrictive_hook(), whatever -- with the translation layer. When the translation layer receives a call to its hook from the base kernel (via security_ops->hook()), the translation layer calls each of the hooks registered by the policy module, and then combines their results in an appropriate way and returns that to the kernel. This exposes the restrictive/permissive/audit/... distinction in the interface that the policy modules see, but hides this distinction in the interface that the base logic sees. Of course, such a scheme would be entirely optional, and a module that wanted to hook directly into security_ops without using such a translation layer would be free to do so. _______________________________________________ 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 08 2001 - 17:25:40 PDT