On Wed, 31 Oct 2001, Casey Schaufler wrote: > Don't give me any of that crap. The differance has been > demonstrated to be neglegable. If we came in with authoritative > hooks that were two lines and three K smaller you'd stiil say that. Negligible in terms of number of bytes and number of lines. But look at the patch contents for a moment. Inserting a call to a hook and a return on error is less invasive than changing the existing kernel access control logic to save its result in a temporary variable, continue processing anyway, skip over any remaining checks if an earlier check failed, and then call the hook and return on error. > Oh my gosh! you mean, a loadable security module might > actually change the security enforcement? Oh No! > And here it was, I thought that was what we were out > to accomplish. No, we're not trying to make it easier for security modules to introduce a vulnerability in the base kernel access control logic. > Red Herring. Why? It is true that the more invasive your changes, the greater risk of introducing a bug into the base kernel logic. If you don't believe that, then you still really believe in moving all of the kernel logic out. > > but have essentially dropped any other > > requested changes. > > Bullshit. Take that back. I fart in your general direction. > Your mother smelt of elderberries. Sorry, I don't understand, and no need to be rude about it. To be precise, I'm referring to the earlier discussion about the need to change kernel code paths to avoid early short circuits and to ensure that the hooks are "truly" authoritative. Richard dropped that thread and was satisfied with just the basic authoritative hooks patch. -- 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 Oct 31 2001 - 09:44:45 PST