Ok, so there seem to be two objections to adopting the new LSM patch as a replacement for the current LSM patch: 1) There is the view that we would be better off with simply restrictive hooks (other than capable) rather than authoritative hooks. Arguments in favor of this view seem to be as follows: a) The permissive behavior supported by the authoritative hooks duplicates the permissive behavior of the capable hook and only offers finer granularity, b) There is less need for finer granularity permissive behavior than for finer granularity restrictive behavior, and c) It is easier to verify restrictive-only behavior with purely restrictive hooks. Another potential argument in favor of this view is consistency - we cannot always provide authoritative hooks, since the existing logic cannot always be colocated with the hook or cannot be easily decoupled from the functional logic. Arguments against this view are as follows: a) Fine-grained permissive behavior would be a useful feature to support in the future, e.g. allowing a process to override DAC on certain sets of files rather than on all files, b) The duplication is no different than in the restrictive case, c) Verifying that a module is purely restrictive is a module issue, not something that should be hardcoded into the kernel. Even if we choose to go with restrictive-only hooks, I would still advocate working from the new LSM patch as a starting point. The current LSM patch has a number of operations where the LSM hooks are strictly permissive, whereas the new LSM patch at least always offers restrictive/authoritative hooks on all hooked operations. Furthermore, the new LSM patch provides finer-grained restrictive/authoritative hooks through the addition of new parameters and it tries to be more consistent about returning the hook return values. 2) The new LSM patch doesn't address moving capabilities into a module. However, I don't see that as a real obstacle - my plan is to address capabilities in the new LSM patch, but I first wanted to come to a consensus on the following questions: a) Do we need to move the capability bits out of the task_struct and linux_binprm structures? Both? Either? Neither? b) Can we limit our changes to the core capability logic, i.e. the logic within capable, the logic within the capability system calls, and the capability-specific computations in compute_creds, ptrace, and set*id? Can we leave all existing capable calls unchanged? I also wanted to ensure that when we move the capbilities into a module, we keep a working base kernel with useful security behavior. Again, I would advocating working from the new LSM patch once these decisions are made, selectively integrating changes from the current LSM patch as desired if they are consistent with the decisions. The current LSM patch has some internal inconsistencies in its approach to capabilities and is in an in-between state that isn't really satisfying, since it has been evolving in an ad-hoc fashion. Let's try to come to a consensus on these issues quickly. -- 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 : Thu Jun 14 2001 - 05:45:44 PDT