On Fri, 3 Aug 2001, KRAMER,STEVEN (HP-USA,ex1) wrote: > To be fair, the translation of the restrictive hooks to before the DAC > checks would continue to satisfy the needs of all of the list above except > SubDomain, and in its place would be SGI. (That is, the > proposition isn't that all the above projects succeed vs. SGI succeeding, > but the translation will affect only 2 of the projects.) On the > other hand, the change away from restrictive hooks would allow all of the > projects to succeed. SELinux has an auditing/logging facility and a development mode analagous to the SubDomain bitch mode for assisting us in creating policy configurations. So we also would prefer to avoid logging spurious denials that are handled by DAC. And my impression is that SGI hasn't made its case that it truly needs the hooks before the DAC logic for MAC. As others have observed, returning different error codes is the module's problem (and an application's nightmare). From a restrictive perspective, it makes sense for all of the hooks to occur after the existing kernel checks. The placement of the hooks and the use of restrictive hooks doesn't guarantee "simple assurance", but it does make it easier to verify. > Maybe what's needed is a principle that states that the inclusion of a > project always comes before potential performance problems in any one > (or plurality?) of projects. This should only be true for projects that fall within the scope of Linus' mandate. It doesn't mean that we should try to accomodate every kind of kernel security project that exists. -- 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 : Fri Aug 03 2001 - 09:18:37 PDT