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 ssmalleyat_private _______________________________________________ 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 - 12:02:38 PST