Re: Authoritative Hooks

From: Casey Schaufler (caseyat_private)
Date: Fri Nov 09 2001 - 09:05:48 PST

  • Next message: Stephen Smalley: "Re: Authoritative Hooks"

    Stephen Smalley wrote:
    > Not exactly.  The capable call doesn't have any object information,
    Ah, but it needs it, because ...
    > 1) The security module's capable hook function would always return
    You are assuming that these capabilities are applied only to
    file system objects. They are also applied (or should be) to
    SysVIPC objects, sockets, and any other thingies with access
    control. You don't want DAC overridden on message queues just
    because you've got ACLs on file system objects. You also have
    to take into account that different file systems may have
    different access policies, with one using POSIX ACLs, one
    NFSv4 attributes, and a third with NT ACLs. Capable()
    has to have access to the object information to make these
    An alternative is to have a seperate capability for every
    check in the system. This does not address the issue of
    per-filesystem semantics, and would result in Too Many
    > I believe that this is functionally equivalent to making the permission
    > hook authoritative.  ... , but it appears to
    > work just fine in this case, and this appears to be sufficient for POSIX
    > ACLs.
    Like I said, you Could do it. It's not as simple as you
    make it out to be because the U2X access control and privilege
    policies are more "sophisticated" than methinks they should be.
    Casey Schaufler				Manager, Trust Technology, SGI
    caseyat_private				voice: 650.933.1634
    casey_pat_private			Pager: 888.220.0607
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Fri Nov 09 2001 - 09:08:28 PST