On Thu, 2025-11-13 at 12:06 +0800, Coiby Xu wrote: > On Fri, Nov 07, 2025 at 02:28:13PM -0500, Mimi Zohar wrote: > > On Thu, 2025-11-06 at 17:15 -0500, Mimi Zohar wrote: > > > On Thu, 2025-11-06 at 21:29 +0800, Coiby Xu wrote: > > > > On Wed, Nov 05, 2025 at 03:47:25PM -0500, Mimi Zohar wrote: > > > > > On Wed, 2025-11-05 at 08:18 +0800, Coiby Xu wrote: > > > > [...] > > > > > > > > > > Hi Coiby, > > > > > > > > > > Based on the conversation with Paul, there is no reason to remove the > > > > > existing > > > > > security_kernel_post_read_file() call. > > > > > > > > > > The changes are similar to the 2nd link, but a bit different. > > > > > - Define a single enumeration named READING_MODULE_COMPRESSED. > > > > > > > > > > - In module/main.c add a new security_kernel_post_read_file() call > > > > > immediately > > > > > after decompressing the kernel module. Like a previous version of > > > > > this patch, > > > > > call kernel_read_file() with either READING_MODULE or > > > > > READING_MODULE_COMPRESSED > > > > > based on MODULE_INIT_COMPRESSED_FILE. > > > > > > > > > > - In ima_post_read_file() defer verifying the signature when the > > > > > enumeration is > > > > > READING_MODULE_COMPRESSED. (No need for a new function > > > > > ima_read_kernel_module.) > > > > > > > > Hi Mimi, > > > > > > > > Thanks for summarizing your conversation with Paul! I can confirm Paul's > > > > approach works > > > > https://github.com/coiby/linux/tree/in_kernel_decompression_ima_no_lsm_hook_paul > > > > > > > > While testing the patch today, I realized there is another > > > > issue/challenge introduced by in-kernel module decompression. IMA > > > > appraisal is to verify the digest of compressed kernel module but > > > > currently the passed buffer is uncompressed module. When IMA uses > > > > uncompressed module data to calculate the digest, xattr signature > > > > verification will fail. If we always make IMA read the original kernel > > > > module data again to calculate the digest, does it look like a > > > > quick-and-dirty fix? If we can assume people won't load kernel module so > > > > often, the performance impact is negligible. Otherwise we may have to > > > > introduce a new LSM hook so IMA can access uncompressed and original > > > > module data one time. > > > > > > ima_collect_measurement() stores the file hash info in the iint and uses > > > that > > > information to verify the signature as stored in the security xattr. > > > Decompressing the kernel module shouldn't affect the xattr signature > > > verification. > > > > In the case when the compressed kernel module hasn't previously been > > measured or > > appraised before loading the kernel module, we need to "collect" the file > > data > > hash on READING_MODULE_COMPRESSED, but defer appraising/measuring it. > > > > An alternative to your suggestion of re-reading the original kernel module > > data > > to calculate the digest or defining a new hook, would be to define > > "collect" as > > a new "action" and pass the kernel_read_file_id enumeration to > > process_measurement(). IMA_COLLECTED already exists. Only IMA_COLLECT > > would > > need to be defined. The new collect "action" should be limited to > > func=MODULE_CHECK. > > > > The downside of this alternative is that it requires a new collect rule: > > collect func=MODULE_CHECK mask=MAY_READ uid=0 > > appraise func=MODULE_CHECK appraise_type=imasig|modsig
As it turns out, the "collect" rule is unnecessary. On READING_MODULE_COMPRESSED, process_measurement() should calculate the compressed file hash. Extending the IMA measurement list and verifying the signature can then be differed to READING_MODULE. > > Thank for suggesting an alternative! I've implemented the idea in > https://github.com/coiby/linux/tree/in_kernel_decompression_ima_collect > > Note besides a new collect rule, another change is needed. Currently, > process_measurement only accepts enum ima_hooks thus it can't tell if > it's READING_MODULE_COMPRESSED so to only do collect action. So I > create a fake MODULE_COMPRESSED_CHECK func. Correct, either extending process_measurement() with the read_idmap enum or defining the fake hook would work. > > And for the idea of re-reading the original kernel module data, it has > been implemented in > https://github.com/coiby/linux/tree/in_kernel_decompression_ima_no_lsm_hook_paul > > Both branches have applied your requested three changes including > respecting the 80 char line limit. Additionally, I made a change to the > IPE LSM because of the new READING_MODULE_COMPRESSED kernel_read_file_id > enumerate. > > After comparing the two implementations, personally I prefer re-reading > the original kernel module data because the change is smaller and it's > more user-friendly. But if there are other reasons I don't know, I'll > post the patches of the new collect action approach to the mailing list. The "re-reading" option fails some of the tests. As the "collect" rule isn't needed, let's stick with the first option. -- thanks, Mimi
