Re: sys_setpriority error

From: Stephen Smalley (sdsat_private)
Date: Thu May 31 2001 - 06:36:42 PDT

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

    > 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
    Stephen D. Smalley, NAI Labs
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Thu May 31 2001 - 06:38:30 PDT