Re: Authoritative Hooks

From: Stephen Smalley (sdsat_private)
Date: Fri Nov 09 2001 - 12:00:45 PST

  • Next message: Stephen Smalley: "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.
    Well, first, you are grasping here, since I've already noted that these
    particular capabilities aren't used for System V IPC objects. Even if they
    were, we have hooks in the System V IPC code that could be used
    authoritatively if you universally granted this capability.
    But I understand what you are trying to say about wanting to provide
    different behaviors for capable() depending on the object type.  However,
    there are two points in response:
    1) You don't truly need to provide different behaviors for capable.  You
    can universally grant the capability and then provide different behaviors
    in permission based on the object type.  Your permission hook would
    implement the default kernel logic for non-files and would implement the
    combined kernel logic + POSIX ACL logic for files.  Also, note that your
    security module would have already determined that an inode corresponds to
    a file and would have likely obtained the ACL and stored it in the inode's
    security field when the post_lookup hook function is called, prior to any
    calls to the permission hook function.  So the permission hook function
    could very quickly determine whether it is dealing with a file or not and
    apply the right logic.
    2) If you have a complaint with the capable interface and calls, take it
    up with the Linux-Privs people.  They defined the kernel function for
    capable.  LSM just happened to hook into it to leverage their work and to
    avoid having to insert its own hook in every location a capable call
    already exists (>500).
    Stephen D. Smalley, NAI Labs
    linux-security-module mailing list

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