On 1 Jun 2001, David Wagner wrote: > Titus D. Winters wrote: > >> > 2. Maintain current set of hooks and push logic out of the kernel and into > >> > the module to avoid placing hooks in compound conditionals. > > > >Yes, this is certainly an invasive solution, but not only is it the most > >general, it is the most elegant as well. > > Elegant? Not from a software engineering point of view. > Almost every module will have a cut-and-pasted copy of the base > logic. Software engineering teaches us that code duplication is > bad: If you ever want to change that code, making the appropriate > change in all necessary places is difficult. I know I'm going to get into trouble here, but ... doesn't that presume that all the changes are going to be the same? You're engineering other people's projects that way. Yes, universally shared code should be in ONE place... but putting it in one place in THIS arena *requires* it be universal, when it may not be. > > >> > 3. Maintain current set of hooks and keep logic in the kernel. Add an > >> > argument to hooks to show whether the kernel was going allow or deny the > >> > action. > > > >I think, as a gut reaction, that this is going to make the hook checks in > >the base kernel a lot ugly and more incomprehensible. > > I don't think so. > if (err = security_ops->hook(x, y, z)) > goto out; > becomes > if (err = security_ops->hook(err, x, y, z)) > goto out; > I don't see why you consider the latter ugly and incomprehensible. I don't either, except if the value of "err" is possibly ignored some places it's a waste of time to precalculate it. > It's not elegant, but it doesn't seem ugly, either, and it seems pretty > easy to understand what it's doing. What am I missing? No, it's not "ugly" in my opinion, either. Just a "less efficient" solution in some cases... perhaps not the MAJORITY of cases, NOW, but the LSM interface shouldn't "impose" anything on the module-provided security subsystem. In this case, it's imposing the "need to wait for God Kernel to speak", if not any requirement that the module listen. * * * * * You know, some weeks ago we argued about the (nominal) impact of an call-possibly-to-donothing vs. a check-and-call in modern architectures. Now we're arguing if we should do actual decisionmaking that's not necessarily needed or not. I see a parallel, somehow. We elected to call-the-possibly-dothing to save a few measly fractional CPU clocks! Is a whole decision-making tree less costly? > > -- David > 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 : Fri Jun 01 2001 - 11:38:42 PDT