* Stephen Smalley (sdsat_private) wrote: > > On Thu, 31 May 2001, Chris Wright wrote: > > > I totally agree that this should be consistent. The problem is that > > capabilities is fundamentally about overriding restrictions (at least that's > > my read of the P1003.1e draft). Perhaps the changes to capable() calls > > should be reverted, and the hooks (like setnice()) should be placed apart > > from other authorization criteria to give the module authoritative control. > > My vote is for this approach. I see three alternatives for this approach: 1) Leaving the capable() call as it is now -- a simple wrapper for security_ops->capable(). This keeps the capabilities module. 2) Put the capablilities check back in capable() and add security_ops->capable() to the guts (as you've mentioned earlier). This would eliminate the capabilities module. (NOTE: I think this could define the beginning of maintaining two sets of hooks. A permissive set (born from capable()) and a restrictive set (those we add). 3) Revert completely to the old capabilities checks and rely completely on the hooks we add. Again, this would eliminate the capabilities module. I think that this would also require either: A) eliminating the possbility of permissive hooks. B) passing results of kernel logic (including the capable() check) to the module (once know as option #3). I don't have any problem with eliminating capabilities as a module. In fact, I am in favor of it ;-) I'm also not opposed to eliminating the possbility of permissive hooks. Leaving capabilities in the kernel proper means the dummy/default could simply return 0 (or allowed) as it does now, and that would take on meaning. -chris _______________________________________________ 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 : Mon Jun 04 2001 - 19:27:36 PDT