Stephen Smalley wrote: > > 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. You're right. I'm thinking in terms of a scheme which actually allows me to implement the policies which I need to achieve my goals. If I have POSIX ACLs and the current scheme my required patch, which replaces the LSM hook with the ACL code, is much more invasive than an LSM which allows me to do the ACLs using it. > > 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. One of the security policies put forth initially is the NULL policy. Yes, you've argued that that can be done by whacking the capability code. That is but one example of a reasonable policy which is "less" restrictive than the "traditional" U2X policy. Some misguided souls want policies that are different from the traditional, and I don't believe it's either my place or your place to tell them otherwise. > > 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. Yes, I still really believe in moving all of the kernel login out. I've been willing to tolerate other schemes in the spirit of getting everyone what they need. Alas, I feel that spirit is not shared. We are certainly not getting what we need, and don't feel that the compromises we've been willing to make are being meet from the other side. > > > > 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. Sorry about the Pythonesque insults. They were not meant personally, and I am out of line. > 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. My response is based on the claim that Richard dropped any other requested changes. He has accepted every change proposed, save the two where there were conflicting proposed changes. This is in the spirit of working together. -- 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 : Wed Oct 31 2001 - 10:43:38 PST