Re: sys_setpriority error

From: Jesse Pollard (pollardat_private)
Date: Thu May 31 2001 - 08:46:01 PDT

  • Next message: Casey Schaufler: "Re: sys_setpriority error"

    Stephen Smalley <sdsat_private>:
    > > The current implementation allows the module to override other factors in
    > > giving you permission.  It does _not_ allow the module to override other
    > > factors in denying permission.  I suspect this is a pervasive issue.  I took
    > > the _very_ conservative approach with the capability_module and the
    > > placement of this hook.  The current implementation preserves the
    > > functionality _exactly_ as it is in the non-lsm kernel.
    > 
    > I was assuming the opposite for the hooks - that they were intended
    > to allow the module to deny access where it would otherwise be granted.
    > In fact, as you mentioned in a different message, this is true
    > for a number of the hooks.  The ptrace hook is a good example where
    > confusion seems to exist.  The calls to the ptrace hook currently allow
    > the module to deny process tracing even if the base kernel logic would
    > allow it.  This is the desired behavior for the SELinux module. But the
    > capabilities plug seems to expect the hook to only be used to grant
    > process tracing if the base kernel logic would
    > deny it, since it always checks the CAP_SYS_PTRACE capability 
    > (except in the TRACEME case), which should only actually be checked
    > if the base logic fails.  So there is a mismatch between the way
    > in which the ptrace hook is being called and the way in which
    > it is being implemented in the capabilities plug.
    > 
    > It seems like we either need to push the entire access control logic
    > into the hook functions (so the hook functions can combine their
    > new logic with the old logic in any arbitrary way) or we need to
    > provide separate hooks for overriding grantings and overriding
    > denials. 
    
    I believe (from other conversations) that that is the plan, but only after
    the security module(s) can be shown to work properly, then the other logic
    would be moved to the module.
    
    It may take some political wrangling, because a user that chooses not
    to include the LSM would suddenly lose all security controls once the
    logic is moved.
    
    -------------------------------------------------------------------------
    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 : Thu May 31 2001 - 08:47:31 PDT