On Wed, 22 Aug 2001, Greg KH wrote: > Personally I don't like it. It allows a module to modify the original > logic that is in the kernel too easily. For right now I think we should > avoid doing this. Well, actually, the module can already use the existing capable() hook to completely override the DAC logic in the base kernel and can then implement any arbitrary logic it desires. The only difference is that with the current LSM patch, we only need to audit a single hook function (capable) to ensure that the module doesn't accidentally do this, versus having to audit all of the authoritative hook functions. But in reality, we need to carefully audit all of the hook functions anyway, since a bug in any hook function could corrupt a kernel data structure and cause a subsequent change to the kernel logic, as mentioned earlier by jmjones. I think that the more significant concern is that the authoritative hooks require more invasive changes than restrictive hooks in many cases (especially when dealing with complex sequences of DAC logic), so the patch is larger and less clean, and the potential for introducing a bug into the base kernel is higher. The latter concern can be addressed by a careful audit of the kernel patch. The size and cleanliness of the patch could affect acceptability by the kernel developers, so that may be a real concern. -- 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 Aug 23 2001 - 05:08:14 PDT