Re: Authoritative Hooks

From: Casey Schaufler (caseyat_private)
Date: Fri Nov 09 2001 - 11:14:42 PST

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

    Stephen Smalley wrote:
    > On Fri, 9 Nov 2001, Casey Schaufler wrote:
    > > 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.
    > No, I'm just assuming that a call to a LSM hook occurs before or after
    > each check of these particular capabilities, so that we can use the LSM
    > hook to authoritatively control the operation when we universally grant
    > the capability.  If you search the Linux kernel sources for CAP_DAC_*,
    > you'll see checks of these capabilities in vfs_permission and
    > nfs_permission, both of which would be called from the Linux permission
    > function, which also calls the LSM permission hook afterwards.  You'll
    > also see a check of CAP_DAC_OVERRIDE in the proc_pid_readlink and
    > proc_pid_follow_link functions, but in these cases, you have a LSM hook
    > call prior to the call to these functions (in sys_readlink and
    > do_follow_link).  So a security module can universally grant these
    > capabilities and use the permission, readlink, and follow_link hook
    > functions to provide authoritative behavior for file accesses.
    You are still ignoring non-filesystem objects. You have explained
    how it all works on file system objects, but not on other objects.
    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 - 11:17:26 PST