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

From: Stephen Smalley (sdsat_private)
Date: Tue Jun 05 2001 - 10:37:56 PDT

  • Next message: Chris Wright: "Re: permissive vs. restrictive issue and solutions..."

    On Tue, 5 Jun 2001 jmjonesat_private wrote:
    
    > I'm trying hard to envision this.  So leave ALL the logic untouched in the
    > kernel and move ALL of the capability stuff to the module behind
    > a unique set of hooks, in essence, reverting the places where previously 
    > we'd "mixed"?
    
    We're still moving the capabilities logic.  But the capabilities logic
    is NOT the calls to capable.  It is the contents of the capable
    function, the capabilities processing in execve, and the capabilities
    system calls.  That is what must be moved into a module (and
    what has already been moved, except for the system call code).
    So we leave the capable calls untouched in the kernel, reverting the
    ones that have been changed already.
    
    > Reverting to:
    > 
    > if (p->uid != current->euid &&
    >     p->uid != current->uid && !capable(CAP_SYS_NICE))
    > 
    > >From the current
    >
    > no_nice = security_ops->task_ops->setnice(p, niceval);
    > if (p->uid != current->euid &&
    >     p->uid != current->uid && no_nice) {
    >     error = -EPERM;
    >     continue;
    > 
    > Around line 217 in sys.c, for example, but moving the whole
    > no_nice thing to the MODULE side of the equation and cleanly intercepting
    > the "capable" call instead?
    
    Yes, other than the part about moving the no_nice thing.  The
    modules just implement capable() directly, as is already done
    by the capabilities module and the SELinux module.  There
    would still be a setnice hook defined by LSM and called by
    the kernel, but it would be authoritative and separate
    from capable.  For example:
    
      no_nice = security_ops->task_ops->setnice(p, niceval);
      if (no_nice) {
         error = no_nice;
         continue;
      }
      if (p->uid != current->euid &&
          p->uid != current->uid && !capable(CAP_SYS_NICE))
          error = -EPERM;
          continue;
      }
    
    > On first blush, if I have it right, I can't say I don't like it. :)
    > It moves the LSM calls into an LSM, leaving more of the kernel alone,
    > but doesn't hobble the LSM's ability to be more permissive or restrictive 
    > with regard SPECIFICALLY to capabilities. (I think.)  Is that generally
    > correct?
    
    Again, I'm not sure what you mean by moving LSM calls into an LSM.
    But it does leave more of the kernel alone, and it doesn't
    have any impact on the ability of LSM to support capabilities.
    
    > In essence, other than the capable() hook, we're reduced to
    > restrictive-only in where the logic is inserted in the kernel
    > UNLESS ... um... what?  I'm not understanding "easily", I guess. 
    > Does this move some logic to the module, with a flag that informs 
    > the module if the logic in the kernel may have allowed a 
    > "permissive response" (a la "option #2"), or leave the logic in 
    > the kernel and supply the "kernel's decision" to the module a la 
    > "option #3"?  I'm guessing the latter, but I'm foggy here.
    
    Using the existing capable() hook, we can already support
    "permissive" behavior (i.e. the ability to grant a permission
    that would be denied by the Linux DAC logic) based on the
    state of the current process.  In cases where we want to
    support finer-grained "permissive" behavior based on the
    state of a target process or object and it is possible to
    colocate the authoritative hook with the existing logic,
    we can add an extra parameter to the authoritative hook to allow
    it to support such behavior.  That could take various different
    forms - the hook could be called prior to the base logic,
    and set a dac_override output parameter to indicate that
    if it said ok, the base logic should be skipped, or the
    base logic could be performed first and the result passed
    to the hook, and the hook could simply make the final decision.
    
    --
    Stephen D. Smalley, NAI Labs
    ssmalleyat_private
    
    
    
    
    
    
    
    _______________________________________________
    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 : Tue Jun 05 2001 - 10:40:56 PDT