On Fri, 1 Jun 2001, 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. > > > > > > this allows for flexibility at the expense of rebuilding kernel logic in > > > the module. really calls for stacking modules. looks like an invasive > > > kernel patch (may be a hard sell). > > > > On the other hand, since this is the most general solution and since it > > would allow even the base access control logic to easily evolve over time, > > this could be a selling point. Also, it seems like we are already on the > > path to an invasive kernel patch, since you are seeking to replace many of > > the existing capable() calls and they are so pervasive. But I agree > > that this would be a lot of work and would be risky. > > Yes, this is certainly an invasive solution, but not only is it the most > general, it is the most elegant as well. It keeps the hooks simpler, it > allows for very simple streamlining, and (the way I envision it) it is at > least as simple to develop for as option #3, if not more. We shouldn't be > getting any complaints from the embedded folk, since the minimalist hooks > could be even smaller than the existing logic (which may or may not be > wise, but is possible.) And as was mentioned, we are already going to be > replacing all of the capable() calls, at this point we are going to be > invasive no matter what. Is it possible for us to check if such a > paradigm would be accepted before we get too far down this path? I can't > see another solution that is as desirable at this point, but we do need > _a_ solution. What it does is prune back the kernel even farther before we "graft" LSM onto it. To follow the metaphor: you can't get a good graft if you don't have healthy root stock. > > > > 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. > > > > > > this allows for flexibility, but i'm not sure it builds a consistent > > > interface. hooks that we've added beyond capabilities are not always in > > > conjunction with kernel restriction tests. guess we can always pass in > > > "kernel would've allowed this" in those cases to build consistency. > > 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. The kernel is > already complicated enough, it would be nice not to make it any worse. Well, "beauty is in the eye of the beholder"... my thought is it increases overhead. If the developer of the module WANTS the kernel's advice, great... let the code in the module reproduce the original tests. If the strategy in place in the module would result it in "overriding" the kernel's "advice" always, why pay the cost? Yes, it's invasive... but, really, we're invading a whole area of the kernel to begin with... we're trying to "rip out" capabilities and move them out to a module (or not, in the case of the "toss them" argument)... we might have to go a little deeper to get a "clean excision". > > My vote is certainly for #2. > > -Titus > My vote is uncertainly for #2. My arguments against #3 are not so much technical as aesthetic (same as Titus' "gut reaction" I think)... if we're moving security OUT, let's get as much of the logic out as possible and leave as few "strings" as we can. That, and, the only "clean" way I can feel happy about #3 is to leave the capabilities in the kernel altogether and it might be easier to sell the whole package if we listen to "Linus specifically said that he would like to see the capabilities mechanism moved out of the kernel into a module." Okay, since we've not established a "ONE PERSON, ONE VOTE" rule, my vote is 1 for #2, 2/3 for #3, and 0 for #1 (it just looks too darn messy.) :) Sincerely, J. Melvin Jones Oh, and... P.S. -- TOSSING CAPABILITIES COMPLETELY is a very nice thought, it IS lame, imho, but ... it's there in a standard release so that'd be the most "invasive" (not just codewise) response of all, again in my humble opinion. |>------------------------------------------------------ || 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 - 09:41:47 PDT