On Mon, Jan 25, 2016 at 10:04:18AM -0500, Mimi Zohar wrote: > On Mon, 2016-01-25 at 14:37 +0800, Dave Young wrote: > > Hi, Mimi > > > > Besides of code issues, I have several thing to be understand: > > > > What is the effect to kexec behavior with this patchset? > > - without IMA enabled (kconfig or kernel cmdline) it will be same as before? > > Yes, without IMA configured or an IMA policy, it is the same as before. That's a bit unfair to your work here, this actually paves the way for not only IMA but also other LSMs to vet for the kexec/initramfs given LSM hooks are used now on a common kernel read set of functions. > > > - with IMA enabled for kernel bzImage, kexec_file_load will check both ima > > signature and original pe file signature, those two mechanisms are > > somehow duplicated. I'm not sure if we need both for bzImage. > > IMA provides a uniform method of measuring and appraising all files on > the system, based on policy. The IMA policy could prevent the original > kexec syscall. On systems without MODULE_SIG_FORCE, the IMA policy > would require an IMA signature as well. (The current patch would > require both, even when MODULE_SIG_FORCE is enabled.) Right, so what this approach has revealed really is that architecturally MODULE_SIG_FORCE should have been an LSM but its not, its also hard to make it an LSM. Now with LSM stacking this might make more sense but that requires work and who knows when and if that will happen. In the meantime we'll live with the fact that enabling MODULE_SIG_FORCE means you want to stack on top of the LSMs you have enabled, the MODULE_SIG_FORCE functionality being all kernel related and perhaps easier to manage / set. Luis
