On Fri, 1 Jun 2001 sarnoldat_private wrote: > On Fri, Jun 01, 2001 at 02:37:32PM -0400, jmjonesat_private wrote: > > 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. It does presume that all serious security modules are going to want > a minimum of traditional Unix security checks. And if, at some point in > the future, it is discovered that the traditional Unix security checks > are missing somewhere, everyone will be forced to update their modules. Um, I take issue to the word "serious", but also admit the point is persuasive from a "group/open software/good for everybody (effort to implement*number-who-must) basis. "Serious" would need tighter definition. How about replace "serious" with "desiring to impose policy restrictions above and beyond the current imposed ones, inclusively." > > I'm hoping the chaining mechanism, together with posix capabilities, > will be sufficient for nearly everyone to avoid reduplicating the Unix > checks.[1] Me too, with the addition of "sufficent for [ANYONE SO DESIRING] to...", chaining/subordinating is a very very powerful feature. > > > I don't either, except if the value of "err" is possibly ignored some > > places it's a waste of time to precalculate it. > > The checks in place to compute "err" are likely less than the checks to > be implemented for everything else. It makes sense to include it (if #3 > is the option we choose) on the off-chance that its answer could speed > up the answer returned by the module by allowing the module to avoid > computing its own answer. Likely. If you make that "<= the check to be implemented for everything else that use them at all", probably. I'll argue the SPECIFIC check that launched this discussion would as easily be handled in the module with the arguments it already has, and could be easily *snipped* out by a module that had some definition of identity other than euid/uid, etcetera... > > > 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? > <clip> I agree with your argument. An "if" is often more expensive than a function call to a success/fail-always function. Therefore, remove the "if"s that are before the hooks to do checking that may not later be needed, was my corollary, and make them at the discretion of the module. While running LMbench, permission is called a HORRENDOUS number of times (well over 6.5 million), binprm_security_ops->compute_creds is only called 2179 times and actually DOES some checking in capability_plug. Are we only talking about "capabilities" or *all kernel checking* here? If we can save 1 CPU cycle per file_security_ops->permission call, we are WAY WAY ahead. If we're only talking about those 2200 calls to binprm_security_ops sheesh, 1... 2... 3... what're we fighting for? GO FOR OPTION #3. The overhead is potentially nominal. (trying to find 10 or 15 "brave souls" to run their commercial sites on a 2.4.x-lsm... so far, no luck, even though I'm offering FREE) :) I'm arguing for moving AS MUCH OF THE CHECKING AS POSSIBLE, capabilities or not, into the module. (Hey, I had to work lsmexample.c data in here somewhere! :)) > -- never using the kernel_suggests parameter -- won't pay much for the > kernel's suggestion, which is probably often very easy to compute > compared to the cost of a botched speculative branch execution. > > I don't think the added cost of the kernel computing its own suggestion > is much of a reason to discount option #3. This, I guess, is a matter of opinion unless it is verified by experimentation (major big job.) #3 allows modules to "go left" and ignore the kernel's result, but the cost is ONLY to modules that don't need those checks in the first place... and it costs nothing or less to those that DO need them... and that is arguably (although I'm not sure statistically) the "major audience." We're also making a black and white differentiation between "needs it" and "doesn't need it"; there are an array of grey areas. Time will tell, but either #3 or #2 is workable for me (depending on the specific implementation.) #2 will serve my purposes better, currently, but only nominally. My opinion still is that #2 is a more general solution, although the issue of "assurance" *IS* compelling. [TO THE CROWD] would the "kernel" opinion ALWAYS be passed to the module about EVERY situation where it has one and, if so, would it ALWAYS be ignorable? "I'm living, in a commercial world, and I am a commercial... um, guy" (Mangled ANCIENT Madonna, I think (yes, I'm THAT olde)) We sell on faith, not proof (and now I've drifted into religion. <BREAK>) Perhaps I should investigate a #define EASILY_PROVABLY_BETTER switch in my code. ;) > > (And yes, I am basing this in large part on my experiences with > unrolling loops; in some cases, the execution speed of my software was > linear with respect to the number of 'if' statements, not really > noticable with the other instructions I was running. :) > I'll take anecdotal experience over theoretical argument most days. "Any model that exactly reflects reality must be exactly as complex as reality... anything less is an approximation." and I've "NEVER MET AN APPROXIMATION I [REALLY] LIKED." I hope I can get to USENIX, all that will make a lot more sense once you see me (look for the guy with a ponytail, beard, and a cowboy hat.) > > [1]: I'm hoping, that since Caldera bought SCO a little while ago, no > one will sue me for using the phrase "Unix security checks" when > referring to the Linux kernel. If Caldera intends to keep Unix and Linux > seperate (fair enough, they paid the money for Unix[tm]), could someone > let me know before I get sued? Thanks. :) > "All references to "Unix" in this document are typographical errors, resulting from a weak left pinky finger and a very agile right index finger (covered, I think, by the ADA.) They should be construed as "*nix." (ouch, i'm injured. (^_^)) :) 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 - 15:01:49 PDT