Re: Authoritative Hooks

From: Casey Schaufler (caseyat_private)
Date: Fri Nov 09 2001 - 11:41:58 PST

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

    Stephen Smalley wrote:
    > On Fri, 9 Nov 2001, Casey Schaufler wrote:
    > > You are still ignoring non-filesystem objects. You have explained
    > > how it all works on file system objects, but not on other objects.
    > All three of the relevant LSM hooks are hooks on inodes, which are used to
    > represent pipes, files, and sockets.  Your security module can certainly
    > determine whether a given inode represents a pipe, file, or a socket, and
    > only apply the POSIX ACLs processing for files.  SELinux has to
    > distinguish whether a given inode represents a pipe, file, or a socket
    > when it assigns a security identifier and a security class to the inode
    > for later use in permission checks, so you can look at it for an example.
    > Nothing too complex here.
    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.
    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:44:28 PST