On Sat, 2 Jun 2001, Crispin Cowan wrote: > So here's yet another idea: split the LSM interface into two parts, permissive > and restrictive. Designers that want purely restrictive functionality use only > the restrictive parts, and thus get easier/higher assurance. Those who want > permissive functionality can turn it on if they need it. I'll reverse myself on the question of permissive hooks. As I mentioned earlier, SELinux does not currently need or use permissive hooks, but we would like to have them in the long term. However, for the same reasons against migrating all of the logic that I cited in my reply to Howard, I think that trying to implement permissive hooks in our first version of LSM would be a mistake. With regard to capabilities, I would again suggest that we leave the existing capable() calls unchanged, and merely change the guts of the capabilities implementation to call our new hooks (i.e. the capable() function logic and the execve capabilities processing will be moved into the module, as it is currently in LSM). In cases where we want the ability to check more information, like parameters, we can insert a new hook in addition to the existing capable() call rather than changing the existing call. This will reduce the pervasiveness of the LSM changes, allow us to focus our work on directly supporting the needs of our particular security modules, and avoid introducing subtle bugs. -- 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 : Mon Jun 04 2001 - 08:04:30 PDT