A little more clearly, I think, and I submit it for consideration as an option in the new list: Push logic out of the kernel wherever necessary to isolate the "permissive/restrictive" issue. security_scaffold_startup() uses "STANDARD", which is preloaded with subordinate module "DUMMY". STANDARD contains all the existing kernel logic with the hooks evaluated to be "restrictive-only", and calls DUMMY restrictive-only. A function "verify_standard_security()" is added that modules can call... true if STANDARD is the prevailing module, false if it is not. Modules needing the "STANDARD", register subordinately using mod_reg, mod_unreg after verifying standard is in place, and STANDARD replaces DUMMY with the new module. Modules NOT needing "STANDARD", register with register_security(), and subsequently verify_standard_security() fails. If "unregister_security()" is later used, STANDARD is restored, and verify_standard_security() again returns true. Perhaps, "locking" STANDARD (refusal to allow another register) with anything but DUMMY in place is necessary, also. Where capability plug fits into all this ... beats me, it is permissive/restrictive to begin with so messes up the whole "more restrictive" requirement. 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 : Mon Jun 04 2001 - 08:00:24 PDT