On Thu, 14 Jun 2001 jmjonesat_private wrote: > Authoritative combines the needs of audit, permissive, and restrictive. > I'd think if we move to restrictive-only we need to come up with a general > solution for permissive and audit, as well, even if it largely "remains to > be implemented." This will add more potential hooks into the core-kernel, > but dramaticly clarifies the placement of hooks and their function, and > presents the *possibility* of something like a "grep" verification. I think the view being taken by people who favor restrictive-only is that it is sufficient to hook capable() to provide permissive support. That provides a coarse-grained form of permissive behavior. As far as audit goes, we'll hopefully gain some insight from SGI as to what that truly requires. > If the 10 calls that were changed to add kern_retval in dummy_ are truely > representative of everywhere the kernel has an opinion that we can grab, > then the kernel is much less opinionated than I'd thought :), and the > impact is quite minimal. I only made hooks authoritative when the kernel logic was easily colocated and decoupled from the functional logic. So there are many other cases where the kernel has an opinion. -- 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 - 12:58:56 PDT