On Wed, 13 Jun 2001, Chris Wright wrote: > This is why it seems funny to place two hooks together that are essentially > making the same check (since capable is a hook to the module). I think the existing DAC+capable logic is fine, using short circuit evaluation to avoid unnecessary calls to capable(). I think the issue of two hook calls on the same code path is unrelated to the issue of authoritative hooks. The real issue is that there are an existing set of capable() calls in the kernel, and those calls are pervasively used by both the base kernel and by modules, but the interface to those calls is inadequate for security modules that we want to support. So we need to insert our own hook calls with finer-grained interfaces, whether we are being restrictive, permissive, or authoritative. But it isn't practical for us to replace all of the existing capable() calls (especially since they can occur from modules as well as the base kernel), so we end up with duplication. If we only insert our own finer-grained hooks and do not insert a hook into capable, then we lose coverage. If we only use capable and do not insert our own finer-grained hooks, then we lose flexiblity (and the ability to support most of the modules under consideration). -- 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 Jun 13 2001 - 12:58:28 PDT