Re: Authoritative Hooks

From: Stephen Smalley (sdsat_private)
Date: Fri Nov 09 2001 - 12:17:16 PST

  • Next message: Casey Schaufler: "Re: Authoritative Hooks"

    On Fri, 9 Nov 2001, Casey Schaufler wrote:
    > The point is that if I have a non-filesystem object, such as
    > a SysVIPC message queue, and CAP_DAC_OVERRIDE has been overridden
    > I now need a hook in the message queue code which re-instates
    > the capability check authoritatively. By changing the behavior
    > of capable() for all cases I have introduced a situation where
    > I sometimes (i.e. file system objects) want the "new" capable()
    > behavior and other (i.e. not file system objects) want the
    > traditional capable() behavior.
    One other clarifying point:  When I talk about universally granting
    certain capabilities in order to bypass the built-in kernel logic and
    to cause the corresponding LSM hook(s) to be authoritative, I only mean
    that the security module's capable hook function always returns success to
    the kernel for those capabilities.  Internally, the security module is
    likely to have its own private capable function that it uses for
    truly testing capabilities in the hook functions in order to provide the
    default kernel logic, possibly in combination with other logic.
    Stephen D. Smalley, NAI Labs
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Fri Nov 09 2001 - 12:18:23 PST