On Tue, 31 Jul 2001, Crispin Cowan wrote: > jmjonesat_private wrote: > > > Authoritative hooks are generally useful and modules that need the "simple > > assurance" argument can use a stacked module that guarantees it. > > That's an interesting idea. However, in trying not to change too many variables at > once, I think it's important that this idea not mandate any additional substantive > changes to the LSM interface itself. JMJ, do you believe that your "simple assurance > preserving module" can be made stackable without additional LSM changes? > We've given it a look, and the results are more mixed than my intuitive evaluation suggested to me... 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. 2) The module could provide somewhat MORE assurance value if it had the results of the in-kernel checks as an argument, protecting the return value in a "bottleneck" where it could be more easily shown that a permission could never be returned if access was denied by the in-kernel checks. 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. How valuable simple assurance is and if the cost is worth the benefit would have to be evaluated on a product by product basis. > > > I'll put resources into writing it, since having an open source module allows more > > assurance. This is NOT impossible, but it is not possible (imho) within the > > hooks/interface without tripping the "more invasive" trap that has ALSO been sprung > > many times. > > Could you elaborate? Does going authoritative do the job? What else do > you need? Although it breaks my heart (toasts my butt?) to admit it, going authoritative is NOT absolutely necessary to build a guardian module... however, let me introduce one final plea: Many decisions have been made with regard to the design of the interface using "simple assurance" as a trump card. While the argument "can't return a permission if in-kernel checks would deny" is valid, to a certain extent, with restrictive_only hooks... it now appears to me to be trivially easy to alter kernel structures in ways that turn those in-kernel checks into module puppets, forcing them to return almost any result one wishes. In essence, restrictive_only placement of hooks only HIDES the fact that they are possibly-authoritative. Admittedly, a compromised module is a disasterous thing. End-Of-Game. Heck, if a virus can carry a payload that rewrites vmlinuz (or even dumps a kernel image somewhere and modifies /etc/lilo.conf as root, then reboots (scarey, huh?))... the game is over, too. A subtle bug in a module is probably going to be relatively common, and the current working interface allows bugs to mash and twist kernel structures in ways that make "simple assurance" a very shakey platform to stand on. 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... arguments I believed because they fell in line with my own work. The argument of "simple assurance" tipped the balance, justifiably... but *I* don't see it as being strong enough to support restrictive_only thinking in this new light... since a stacked module (or module-by-module coding) is now necessary to shore up the assurance either way, and can readily force the results to be "restrictive". The idea that "something is better than nothing" ... lock the doors and leave the windows open? That's not much assurance. I don't have all the answers. I don't think this whole group together has all the answers... good theories and ideas fall prey to the 11ty-4 jillion crackers out there every day. I *am* willing to put resources behind a "guardian" module and open it up for review and community revision and ridicule. Since it will concentrate the issue into a shared space between the interface and the module, we can "put our simple-assurance eggs in one basket and watch the basket", and return the interface to authoritative, which is honestly what it *potentially* IS now, and then focus on dealing with the problems and ramifications resulting therefrom... while developers won't be constrained by an argument that was *right*, but didn't actually work out in practice. I can not argue for pulling the DAC (in-kernel checks) out to the module, this is too invasive at this point... but having an authoritative interface might give substance and the benefit of "long standing proof" to the idea out around Linux 3.0 or 4.0, I don't know... but the mechanism might be the same: stack the DAC, prove it, then you have DAC and a GUARDIAN in front of a module ... or modules that want to SUBORDINATE DAC and call it only if, say, MAC fails, can do so ... "in the distant future." > > 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 > > My 0.2 cents (^_^), 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 - 12:43:10 PDT