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

From: Jesse Pollard (pollardat_private)
Date: Mon Jun 11 2001 - 10:53:29 PDT

  • Next message: Chris Wright: "Re: Where Are We?"

    ---------  Received message begins Here  ---------
    
    > 
    > * 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).
    
    This is likely a little early, but:
    
    I think there are two kinds of audit.
    
    1. General audit log (referred to above) where the log module needs/should
       log the security context plus the success/fail result. As to whether
       it belongs in the LSM or not is a separate issue (if not, it must
       request the information from the LSM before passing it to a daemon...)
       It also brings up the issue of what to do when/if the log daemon is
       terminated... (shut the system down after log queue fills? Hang the
       system? panic the system? drop the log entries? I've seen all four, and
       don't like the last one.)
    
    2. A detailed (and correspondingly very massive) audit used to help check
       the LSM implementation. This log may have multiple entries for each
       general audit entry. Sort of like a LSM trace log. This log would
       be usefull to check that a policy (as checked by some static "verifier")
       really was implemented by the LSM correctly; or for tracking down where
       a failure occured.
    
       Much of the supporting code for this massive log should be optional, or
       be switched on/off easily. It would have to be combined with a daemon
       to acually get the log on disk (which may/may not be the same as the
       normal audit log daemon).
    
    BTW, this detailed log is more usefull if/when IPSec gets layered than
    right now.
    
    Just a thought.
    
    -------------------------------------------------------------------------
    Jesse I Pollard, II
    Email: pollardat_private
    
    Any opinions expressed are solely my own.
    
    _______________________________________________
    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:54:47 PDT