Re: sys_setpriority error

From: Chris Wright (chrisat_private)
Date: Thu May 31 2001 - 11:14:09 PDT

  • Next message: Stephen Smalley: "Re: sys_setpriority error"

    * Stephen Smalley (sdsat_private) wrote:
    > > 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.
    I consider the ptrace code broken with repsect to lsm namely because 
    cap_issubset is still being called and there is a ptrace hook yet it doesn't
    replace the capable(CAP_SYS_PTRACE) checks.  This is a known issue.  I will
    a to do list shortly that shows what I know needs to be looked at, including
    some of the things brought up in this current discussion.
    > 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. 
    Yes, I'm starting to think the same.  I'm leaning towards pushing entire
    access control logic into the hook functions to keep from cluttering the
    interface and adding tons of hooks.
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Thu May 31 2001 - 11:17:40 PDT