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 linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Fri Nov 09 2001 - 11:17:26 PST