On Tue, 31 Jul 2001 Valdis.Kletnieksat_private wrote: > On Tue, 31 Jul 2001 17:55:11 EDT, jmjonesat_private said: > > > One minor problem... the hooks need to get authoritative or post-in-kernel > > with a passed value (along the lines of my previous suggestion) to make > > our module really work. Passing the in-kernel checks to the "simple > > assurance" module allows that module to return a refusal therefrom > > pre-emptively, without passing anything to the service routines for the > > hooks. Other problems, like copy-and-pass could be handled by this > > stackable module... > > Well... if we're looking at authoritative hooks again, it's not at > all facetious. > > If we go to authoritative hooks, and stack your module, how close does > that get us to the original "simple assurance" goal? Is this someplace > that a reasonable compromise can be reached? Actually, more close than the current patch allows. If the module accepts a subordinate registration, then imposes the following "filters" to calls to the subordinate hooks, I think it is MORE safe: If hooks are authoritative and in the form security_ops->hook(retval,....) 1) If the passed kernel value returns a failure (ANY FAILURE) when the kernel said "NO", and the return value is that value... REGARDLESS of the return value of the sub-hook. 2) If the hook provides a pointer, the "safe module" copies that structure and passes a pointer to the copied structure, then modifies ONLY the relevant fields in the original structure on return to reflect the changes (subject to community review) that were expected. 3) If the module (based on the above two points) will NEVER allow a permission where there would have been a rejection, we have "arguably simple assurance if the module is loaded" if the module code is open source and arguable, such as making it the capability_plug module, or something along similar lines. I admit: the in-kernel checks would still have to execute and there are performance issues, but the RESULT *could* be claimed to be "fail-safe". The ONLY additional burden on LSM would be "arguing and due dillegence of" the "simple-assurance" module, which might actually be easier than proving each hook and all their subsequent consequences are/is safe. Also, the "fail-safe" code need not be put in the kernel, reducing the "kernel invasion" considerably. Other Benefit: modules that don't NEED the "simple assurance" argument could register directly with the interface and be authoritative, supporting audit and *some* permissive models in Stage I. > > /Valdis > A Good Idea, With Some Interesting Consequences: For Discussion, 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 : Tue Jul 31 2001 - 15:30:34 PDT