On Mon, 4 Jun 2001, Stephen Smalley wrote: > > On Fri, 1 Jun 2001, Howard Holm wrote: > > > In summary, if you haven't already guessed, I'm finding the arguments > > for migrating all security logic into modules more compelling than > > those against. > > Although I agree with the idea of migrating all of the security logic > into the modules in principle, I think it may be a mistake for us > to do so right now for the following reasons: > > 1) It is likely to be politically difficult to gain acceptance > from the Linux kernel developers for such pervasive and significant > changes to the Linux kernel. It seems wiser to go for an incremental > approach - first gain acceptance for a set of new hook calls in the > kernel, leaving the existing base logic alone, and demonstrate the > value of the new hooks through example modules, and then subsequently > lobby for migrating the base logic into the hook functions. 20 years of experience in sales (electronics, insurance, securities, software, and consulting services) causes me to take issue with this argument. We have a "product" that has a certain benefit "B", it has a certain cost "C". B is rather large right now... the whole idea of getting loadable security. Keeping C low makes the cost/benefit, C/B very low, this is true, how low, is a function of what it does to B, too, however. After you sell "plan A", you now have to sell an "add-on". You've already "spent" B, so you, largely have to start again. It's easier to make ONE sale, once, than sell 30 times because the C based on "geez, we already gave you THIS, now you want THAT TOO" grows exponentially, and the "refinements" add B only incrementally. You get maybe ONE or TWO shots, then you are back to reselling the WHOLE PACKAGE, opening "XLSM" total revamps to the bargaining table. If we carefully, before the first sale, do everything we can to optimize, C/B (not focussing merely on C), we are better off in the long term. "We overdesigned to address anticipated future needs" has significant B, and can be bundled into our first, best, pitch. "We'll change it later, wanted to get it done fast, and figured we'd think about it later, wanted to get our foot in the door" really cuts the B. Any way we slice it, this is never going to be a "lead pipe cinch" sale. The best we can do is make sure our position is as strong as possible and our rebuttals to the 3rd order already in place. What if we're suddenly confronted with the "why didn't you make this restrictive only" or "permissive capable" at the table? > > 2) The work factor for changing _all_ of the existing locations > where the base logic exists is quite substantial, does not directly > contribute to supporting _any_ of our security modules, and > could prevent us from making timely progress in this effort. It need not be ALL or NOTHING, just evaluate and put the "salient" logic out. "Salient" being "may be arguably be necessary to address current and 'clearly envisionable' future needs". > > 3) The potential for introducing subtle bugs by trying to migrate > all of the existing logic behind the hook interfaces seems high. > This is especially true since the right location for inserting > our hook calls often does not correspond with the locations of > existing logic, and our hook calls often need more information > than existing logic (e.g. the capable logic is merely based on > process state, and the capable calls often occur immediately on > entry to a system call, before kernel copies are made of > parameters that are needed by the hook). An example of this > can be seen in the existing changes to the delete_module call, > where the hook call doesn't cover all of the same cases as > the original capable() check. > This is true, but we also have at least one incident of introducing (or was it *revealing?*) a "subtle lack of assurance" by mimicking the logic exactly instead of sticking with the current "everybody patches the whole kernel" method. The "area behind the call and where its result belongs in the kernel" needs to be evaluated in every case, somehow. I think we may avoid more bugs than we cause by addressing this issue aggressively now. In summary, making a cheap (low C) product because you're afraid of sticker shock on the other side never really gets you ahead. Making as inexpensive a QUALITY product as possible (low C/B), is certainly the way to go, imho. If it's worth doing, it's worth doing well, and you can argue that the extra C was justified by a commensurate increase in B. > -- > Stephen D. Smalley, NAI Labs > ssmalleyat_private > > 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 : Mon Jun 04 2001 - 09:08:50 PDT