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

From: Chris Wright (chrisat_private)
Date: Mon Jun 11 2001 - 10:18:42 PDT

  • Next message: Jesse Pollard: "Re: permissive vs. restrictive issue and solutions..."

    * 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
    



    This archive was generated by hypermail 2b30 : Mon Jun 11 2001 - 10:23:38 PDT