On Sat, 2 Jun 2001 Valdis.Kletnieksat_private wrote: > On Fri, 01 Jun 2001 12:39:57 EDT, jmjonesat_private said: > > 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? > > OK.. thought experiment time - has anybody contemplated pushing *ALL* > and I do mean *ALL* the security/permission checking off to the LSM? > > I mean all the places where the kernel calls suser()/capable(), > all the places that check user/group/world permissions, etc etc. > > Contemplating this is a good reducto ad absurdum check for "let the > code in the module reproduce the tests". Contemplate the following: > > 1) The number of eyeballs that will look at a check for suser() in > mainline code, and the number of organizations that will have to > fix their code. Answer: Lots of eyeballs, and you only have to > fix the kernel once. > > 2) The number of eyeballs that will look at a check for suser() in > a given LSM module (lots fewer eyeballs), and the number of times > the same problem may need to be fixed. Yes, a blown check in a > given LSM may *seem* to only affect sites that use that LSM, but.... > > I've added a posting from Bugtraq from a while ago that seems to > indicate that we should *EXPECT* multiple people to screw up > multiple modules the same way. > > /Valdis > ... This is a persuasive argument, undeniably. It's also a persuasive argument for not having LSM at all, but putting ALL security into the Kernel... again, reducto ad absurdum. 1) Since all the security would be in the virgin kernel, more eyes would see it, review it, argue it, fix it. 2) There'd be no chance of duplicated errors, since the code would be the code would be the code. Whenever you introduce "options", you divide the audience into subaudiences with differing objectives for evaluating the implementation. Since you have fewer people in "each camp", you have fewer people looking at each solution. LSM provides options. It's going to divide. SELinux people will focus on SELinux solutions, IMMUNIX on immunix solutions, ACME-BUDGET-SECURITY on ACME-BUDGET-SECURITY solutions. Moving the logic from the kernel to the module need not necessarily divide the peer-review/verification. A possible solution might be a common source library say, "standard_security.h" that *can* be #included for every module and contains macros for each moved check, and is commonly reviewed by the community at large. The same macros could be used in the "NO LSM SUPPORT" kernel, an LSM that wishes "same support", or not at all in an LSM that goes another direction. The addition of chaining/stacking opens other opportunities for a "commonly reviewable resource", in the same fashion that the current "standard capability_plug" module needs to be reviewed to assure it exactly reproduces the original kernel logic. Without a chaining/stacking mechanism, EVERY module must independantly verify their code, rather than hooking in a verified capability_plug with some common assurance. Since verification must be done in any case, centralizing as much of what needs to be verified in ONE place makes sense. Having it potentially scattered all through the kernel and also in the LSM just makes it more difficult. By moving it ALL out of the kernel, into a common "access point", it can be done. This approach may be easier with option #2, since #3 will leave more in the virgin kernel that can (and probably will) be changed in the future. Move it ALL out of the kernel, with a shared set of tools that all module designers *optionally* may be able to incorporate if it fits their strategy, and you have "one place" for both LSM and Kernel developers to look to fix and verify. In My Humble Opinion, Of Course, Sincerely, 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 : Sat Jun 02 2001 - 12:20:50 PDT