On Mon, 2020-10-19 at 12:23 -0400, Stephen Smalley wrote: > Why is it that IMA only supports measuring kernel modules if they are > loaded via finit_module(2)? Why can't init_module(2) pass a buffer > with the module content after copying from userspace to IMA and let > IMA measure that buffer? Is that an intentional design choice or just > no one has asked for it? > > At present, it appears that kmod will fall back to using > init_module(2) when kernel modules are compressed on disk, and that > such compression is common in Linux distributions. Hence, if one has > a func=MODULE_CHECK rule, kernel module loading fails unless one > enables module.sig_enforce and even then the modules aren't actually > measured, just signature checked. > > Potential userspace-only solutions are to decompress the kernel > modules (but this deviates from distribution packaging/practice plus > obviously impacts storage) or change kmod to decompress to a tmpfs > file and use finit_module() on that. > > But I'm not sure why we can't just measure the buffer with the > kernel's copy of the module during init_module(2) and get a > measurement that way. Right, nobody asked for it (and lack of time to implement it). I was under the impression that we were moving away from init_module and that eventually it would be deprecated. With Kees' new security_kernel_post_load_data() hook being upstreamed in this open window and the recent IMA support for verifying appended signatures, support for both measuring and verifying kernel modules loaded via the init_module syscall should be possible. thanks, Mimi
