On Sun, 3 Jun 2001, Matt Block wrote: > Crispin Cowan wrote: > > So here's yet another idea: split the LSM interface into two > > parts, permissive and restrictive. Designers that want > > purely restrictive functionality use only the restrictive > > parts, and thus get easier/higher assurance. Those who want > > permissive functionality can turn it on if they need it. > > > > "Split" may be an over-statement. Perhaps just a global > > switch that can disable the permissive interfaces would > > suffice? Then a module designer could turn off > > permissiveness, and be assured that their module will "at > > least do no harm." > > This switch should not be global, in the senses of being either > compile-time, or effecting all modules. If there is any logic > to the "assurance" argument it remains valid if the module in > question simply doesn't access any of the permissiveness granting > hooks. This argues for splitting hooks into permissive and restrictive (exclusive) on the kernel side of the LSM interface, I think. > > My understanding is that it is a project goal to dictate no > security policy but, rather, leave that to each of the modules. > Meddling with the ability of some module to make certain things > more permissive works against this goal. I agree. So "tossing permissive completely", imho, really violates that requirement. > > I think the multiplexor module chaining can actually solve this > problem; if the standard security choices were implemented in > a single module, and if a multiplexor were written that allowed > for overriding particular hooks, it would allow all of the > "default" code to live in one place, and for particular modules > to override this on demand. For those applications that would > require an override this might introduce some additional overhead, > but, I think it would make it even easier to modify policy and > customize the amount of overhead introduced (for instance, an > embedded application could choose to not utilize the default, > multiplexing module but, instead, a super-permissive "return 1" > module). I have a feeling that the "default" permission set > and this multiplexor should be in the same module. This has been my favored solution all along. By going with the original "option #2+" pushing the logic out of the kernel to "somewhere" and simultaneously restoring it in a "common" place so some assurance/verification would be possible. If, for example, that "common module" became an intrinsic part of the LSM patch, and mod_reg/mod_unreg was extended to allow a "requirement" by the subordinate module that it be registering with the "restrictive" module, modules that need a "do no worse" assurance would still have it, or fail to load. Can't Verify I'm Restrictive Only! Please read INSTALL. If the "common place" is a module that can only be first-loaded, there's more assurance (if you allow it to stack farther down the line, the interposing modules COULD "decertify" it), but if it can accept ONE subordinate module registration, then you can hang a multiplexor or whatever under it. Such "families" can be established with or without the requirement of the "restrictive" module, so permissive/restrictive or "couldn't care less about what the kernel would have said" families can all be implemented without much cost to anybody. But, there have been significant arguments that this dilutes the open software review of the original kernel logic. I'm not sure that MUST be true, but I must admit it certainly MIGHT be true. Making DUMMY do the logic, puts it in security.h/security.c, and if DUMMY (um, make that STANDARD) can take one mod_reg/mod_unreg that can verify that STANDARD is loaded, or let register_security/ unregister_security replace it thereafter causing mod_reg/mod_unreg to fail "standard" verify, keeps it in the "after LSM" kernel tree where it legitimately should get "looked at." I think. > > Or was this the discussion of this idea one of the many things > which has already flown over my head in this thread? :) > > -- Matt > > -- > Brainbench Linux MVP > Transcript ID# 355889 > http://www.blockdev.net/ 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 : Mon Jun 04 2001 - 07:37:43 PDT