jmjonesat_private wrote: > > The "old" benefits (can do more hypothetical stuff) we're aware of, but > > decided weren't worth the cost (benefits of simple assurance). The > > "new" benefits are that they may ease the tension between the DAC-firs > > people and the MAC-first people. That is the key. > > Simple-assurance isn't either simple or (particulary) assuring. If you insist, > I'll publish an exploit, I'd be happy to, although I would rather not since I'd > rather not give code to the "enemy". We have discussed this ad nauseum before. That you can write an "exploit" is irrelevant. "simple assurance" is a bug tolerance technique, not a technique to harden the kernel against nasty modules. > And continuingrestrictive_only "eases" the DAC-first people? SGI? I don't > think so. I have no idea what you're talking about. The conjecture is that switching from restrictive to authoritative eases the tension between DAC-first and MAC-first. I've asked that question many times now, and without a strong "Yes!" answer, I'm inclined to stay with restrictive-only. > > "open minded" means not judging issues you don't yet have evidence for. > > We (WireX) considered it, and gathered tons of evidence that DAC-out is > > an impractical idea. Others who went and looked seemed to come to > > similar conclusions. I'm tired of discussing it. It has no chance of > > ever succeeding, so we're wasting our time considering it. > > I don't agree with this. Possibly, I haven't "worn myself out" on the search. I'm convinced, Greg is convinced, Chris is convinced, (IIRC) Stephen is convinced. Even Richard is convinced that it is difficult. So if you don't get it yet, it's time to take it off-line. > Simply put: "it's how we move forward." We move forward by not re-hasing old discussions endlessly. Your initial observation that simple assurance is not as strong as I thought was new to me, but apparently not to Smalley. All the rest of this flame war is old, and not worth repeating. > I'm no PhD, therefore, I probably wasn't indoctrinated adequately into this > thinking, but I *DO* have questions about its validity (suggest your answer may > be useful in a FAQ for subdomain or LSM). The DAC-out issue (which is what I think we're talking about?) has nothing to do with SubDomain. > I'd hope I'd be "corrected" with specific arguements rather than "I'm tired"... The existing DAC logic is not in one place in the existing linux kernel. It is scattered throughout, sprinkled lightly through a whole bunch of functionality code. If you try to move it all to a module, you get: * a huge patch that affects thousands of lines of widely dispersed kernel code * a lot of bugs because the changes to the kernel code weren't quite right, and either broke some security, or broke some functionality * a lot of bugs in the DAC module, as it fails to successfully replicate and integrate the DAC logic in a new context * (I predict) a lot of resistance from Linus et al, who think all of the above is obvious Crispin -- Crispin Cowan, Ph.D. Chief Scientist, WireX Communications, Inc. http://wirex.com Security Hardened Linux Distribution: http://immunix.org Available for purchase: http://wirex.com/Products/Immunix/purchase.html _______________________________________________ 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 : Mon Aug 06 2001 - 12:24:41 PDT