Crispin Cowan wrote: > That looks like an authoritative hook to me. Bad logic in the module could > result in an override of kernel DAC logic. > > I've argued long & hard against permissive and authoritative hooks. I'll > have to think about which one I want more: the simple assurance property, or > DAC/MAC sequence the way I want it. > > What do other people think? I think that if we used authoritative hooks the whole audit issue would be mute, as it would (almost) all be handled in the hooks. If we used authoritative hooks MAC, DAC, audit and ShellAC can be mixed in any order you please, and with any desired relationship. By restricting the LSM to additional policies (i.e. leaving existing code lie) we created the problems we're struggling with today. My experience with SunOS/MLS (became Trusted Solarus), Trusted Irix, and POSIX 1e/2c leaves me convinced that the technical benefits of authoritative hooks are worth the political fight required to get them in. I am not convinced, again based on past experience, that the difference between the politics for restrictive and authoritative hooks matters much. But then, I could be wrong! -- Casey Schaufler Manager, Trust Technology, SGI caseyat_private voice: 650.933.1634 casey_pat_private Pager: 888.220.0607 _______________________________________________ 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 Jul 26 2001 - 10:50:55 PDT