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

From: David Wagner (dawat_private)
Date: Fri Jun 08 2001 - 17:22:37 PDT

  • Next message: David Wagner: "Re: permissive vs. restrictive issue and solutions..."

    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