Re: permissive vs. restrictive issue and solutions...

chrisat_private

* David Wagner (dawat_private) wrote:
> 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.

I don't think any of this would be possible without making the hooks
strictly authoritative either by pushing all access control logic into the
module, or by passing the result of kernel DAC logic to module.
Otherwise I don't think the permissive hooks would take on any meaning.
If the hooks are authoritative, this is a nice way to preserve simple
assurance (i.e. does your translation layer ever call a permissive hook?)

I'm also not convinced that auditing hooks have the same placement
requirements as permissive/restrictive security hooks.  I expect the
audit hook to need to know not only was i authorized (obvious overlap
with security check), but also was i sucessful (here we have overlap
with the post hooks added for file object creation).

-chris

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module