On Thu, Jan 21, 2016 at 1:15 PM, Mimi Zohar <zohar at linux.vnet.ibm.com> wrote: > On Thu, 2016-01-21 at 10:45 -0500, Paul Moore wrote: >> On Thursday, January 21, 2016 08:12:12 AM Mimi Zohar wrote: >> > Paul, Casey, Kees, Jon, Tetsuo does it make sense to consolidate the >> > module, firmware, and kexec pre and post security hooks and have just >> > one set of pre and post security kernel_read_file hook instead? Does >> > it make sense for this patch set to define the new hooks to allow the >> > LSMs to migrate to it independently of each other? >> >> Well, as usual, the easiest way to both get solid feedback and actually get a >> change accepted is to post patches to the affected LSMs. Probably not what >> you wanted to hear, but at least I'm honest :) > > Unless I'm misreading the code, it might be a lot simpler than I > thought. Of the three LSM hooks kernel_module_request, > kernel_module_from_file, and kernel_fw_from_file, the only upstreamed > LSM on any of these hooks is SELinux, which is only on the > kernel_module_request hook. > > After converting the SELinux kernel_module_request hook to use the new > kernel_read_file(), do I then remove the three hooks? Are we > concerned about "minor" LSMs that have not been upstreamed that might be > using these hooks? It should be easy for me to port my LSM to use the new hook. No objections in consolidating things. (Which reminds me to resend my LSM again...) -Kees -- Kees Cook Chrome OS & Brillo Security
