On Wed, 1 Aug 2001, Crispin Cowan wrote: > jmjonesat_private wrote: > > > 1) It appears that passed pointers to structures can be protected by a > > stacked module, even without going authoritative at this time. The > > cost is partially the same as the benefit: structures and substructures > > (etcetera) could NOT be altered unless the guardian module specifically > > allowed it. > > ... > > 3) The cost of this sort of protection, on a scale of 1-10 is somewhere > > around 20. Structures need to be copied and return conditions > > evaluated. Sometimes, it can get pretty "hairy". Justification for > > putting it in a module that ONLY those who REALLY need it would employ. > > I think you're off in the weeds here. I disbelieve that a module that > does full data structure marshalling/demarshalling would be useful. As > you say, the costs are prohibitive. What I thought you were talking > about was a SIMPLE module that would just take the DAC decision, the > module decision, and return whichever is stricter. > > But the kernel pointer problem is hopeless: don't try to solve it. > What you end up with is a lame micorkernel. I agree that I'm way out in the weeds, but I'm pursuing the ideal that was so eloquently argued as being useful. Our evaluation of the cost DOES make it very questionable. As far as the "simple" module, that's a few hours work. No problem. If that's sufficient to turn authoritative to restrictive_only "adequately" for most needs, I'm there! :) Turn the hooks authoritative, I'll provide a module that simply forces the response to be the "more restrictive" of the passed DAC result and the module result... "totally free of charge" (^_^) > > Of course, since its a module, it doesn't impinge on the rest of us, so > go ahead if you see value in it. Personally, I *DON'T* think I'd be using it with my product. Rather, I thought of the idea as something worth exploring if the community in general found it to be very useful. AT LEAST, I saw it something worthy of evaluation. If it doesn't meet a general need, I won't waste the dollars/time. Still waiting on a consensus, and, yes, it does "smack" of microkernel... but it strengthens the simple-assurance argument, which was, apparently, convincing and useful to many. > > > > I remember discussions not long ago that actually seemed fairly "split" > > with regard to authoritative hooks, and have seen pleas and arguments that > > they will be more useful in the future for a variety of interests... > > I perceive the community as currently split on tha authoritative question. > > * Still want restrictive-only hooks: Crispin, Greg, and David Wagner > * Want authoritative hooks: Valdis, Richard Offer, JMJ > > Much of the motive to yield the simple assurance property is the big > pile of stuff that allegedly improves if we go to authoritative hooks. > However, I posted a bunch of issues with those alleged benefits last > night, and I'm still waiting to hear back from SGI as to whether > authoritative hooks (*without* moving the kernel's DAC logic into a > module) make things better for them. If not, we're back to square one. > I'm not sure I saw that post... have had some problems with email related to the wirex changes, but I'll hit the archives and pull it up. > > > The idea that "something is better than nothing" ... lock the doors and > > leave the windows open? That's not much assurance. > > Saltzer & Schroeder make a strong distinction betwen protection for > debugging and protection against threats. "doors locked & windows open" > is useless against an adversary, but is useful against the merely stupid > (bugs). Since we must assume that modules are not malicious, but may be > buggy, locking the door does provide value. Some, but not much, imho... but I will defer to S & S. :) (Your quoting of the literature has been EXTREMELY valuable, at least to me.) I *do* suspect that "simple bugs" in "debugging" are not all that will be faced... bugs open vulnerabilities that can be exploited by adversaries... so the actual issue is somewhere between valueless and valuable. I don't claim to be a scientist... I claim to make things work (in essence, a practical generalist.) I fail, I learn, I succeed. > > Your initial observation degraded my perception of the value of simple > assurance, but did not destroy it. That, plus the big shopping list of > benefits to authoritative hooks pushed me from one side of the field up > onto the fence. I'm anxiously waiting to see if the alleged benefits > will actually pan out. Me Too. (Dear Santa: I want authoritative hooks for LSM for pre-xmas!) (^_^) > > 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 > J. Melvin Jones |>------------------------------------------------------ || J. MELVIN JONES jmjonesat_private |>------------------------------------------------------ || Microcomputer Systems Consultant || Software Developer || Web Site Design, Hosting, and Administration || Network and Systems Administration |>------------------------------------------------------ || http://www.jmjones.com/ |>------------------------------------------------------ _______________________________________________ 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 Aug 01 2001 - 13:43:56 PDT