> > 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. > > 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. My vote is certainly for #2. -Titus _______________________________________________ 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:05:31 PDT