On Wed, 5 Sep 2001, richard offer wrote: > capable() is not a substitute for authoritative hooks, there is > insufficient information available inside the hook on which to make any > decision that is more complex than "is this process running with > privilege". Capable() was never intended to be used as a general purpose > access control vehicle. You misunderstand me. As I've previously explained (both on the list and at the BOF), you can use the capable hook to bypass the kernel DAC logic and can then implement your desired functionality in the restrictive hook. If the capable hook returns 0 (success) for the various DAC-related capabilities, then the restrictive hook is effectively authoritative. The only potential concern is whether the module must then recompute the original DAC decision in the restrictive hook. Chris Wright has suggested that the module may be able to avoid such a recomputation by saving state when capable is called and subsequently using that state in the restrictive hook, since capable is usually only called if the DAC logic failed. Lachlan noted a case (some of the set*id calls) where capable is called prior to the evaluation of the DAC logic, but in that case, the restrictive hook is called prior to any of the kernel logic, so you can still achieve your objective. -- 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 : Wed Sep 05 2001 - 11:38:29 PDT