Significant issue: Our interface passes pointers to kernel structures to the module. For example, security_ops->bprm_ops->alloc_security passes a linux_binprm pointer which is later used in kernel-side checks... It is conceivable that a module COULD change fields in this structure that would later circumvent in-kernel security checks, interfering with the in-kernel checks and, likewise, with the "simple assurance argument". Fields like linux_binprm->uid could be changed, possibly resulting in subsequent compromises of in-kernel checks, resulting in a permission where a failure would be appropriate. This brings into question the "simple assurance" argument for LSM. There are numerous other places where we pass a pointer (*file or *inode or *whatever) that COULD allow the module to change fields and thereby influence subsequent in-kernel checks. I haven't explored these, but, likewise, I haven't heard of anybody else exploring them either. Since ONE vulnerability is considered proof of insecurity, I ask... is this an issue? Should it be fixed? CAN it be fixed? HOW? Or should we reconsider the weight of the "simple assurance" argument and, perhaps, deal with it elsewhere (like in capability_plug (which would become lsm_plug)). If the consensus is "yes, it should be fixed", I'll put manpower on it. Some Solutions: Allow authoritative hooks, which are applicable if the "simple assurance" argument drops below radar, imho. (In essence, abandon the "simple assurance argument" completely.) Build a module (capability_plug?) that copies the structure passed and presents a "local" version to the module, so changes would not percolate back to the kernel, allowing a "simple assurance" argument IFF that module was installed as primary. The performance hit would be significant, but not necessarily IMPORTANT for "secure systems." Incorporate the copy-and-pass strategy in the hooks (this is pretty draconian, imho.) Might be possible in many cases as pass-by-value. Provide PROOF that every pointer to a kernel-side object that is passed in the interface is irrelevant to this problem. Other solutions welcome. 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 : Tue Jul 31 2001 - 12:44:25 PDT