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. One other clarifying point: When I talk about universally granting certain capabilities in order to bypass the built-in kernel logic and to cause the corresponding LSM hook(s) to be authoritative, I only mean that the security module's capable hook function always returns success to the kernel for those capabilities. Internally, the security module is likely to have its own private capable function that it uses for truly testing capabilities in the hook functions in order to provide the default kernel logic, possibly in combination with other logic. -- 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:18:23 PST