[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b9eb78105115a00731b3677a5f3a39d5dde4d2ec.camel@linux.ibm.com>
Date: Thu, 06 Nov 2025 17:15:33 -0500
From: Mimi Zohar <zohar@...ux.ibm.com>
To: Coiby Xu <coxu@...hat.com>
Cc: Paul Moore <paul@...l-moore.com>, linux-integrity@...r.kernel.org,
linux-security-module@...r.kernel.org, Karel Srot <ksrot@...hat.com>,
James
Morris <jmorris@...ei.org>,
"Serge E. Hallyn" <serge@...lyn.com>,
Luis
Chamberlain <mcgrof@...nel.org>,
Petr Pavlu <petr.pavlu@...e.com>, Daniel
Gomez <da.gomez@...nel.org>,
Sami Tolvanen <samitolvanen@...gle.com>,
Roberto Sassu <roberto.sassu@...wei.com>,
Dmitry Kasatkin
<dmitry.kasatkin@...il.com>,
Eric Snowberg <eric.snowberg@...cle.com>,
open list <linux-kernel@...r.kernel.org>,
"open list:MODULE SUPPORT"
<linux-modules@...r.kernel.org>
Subject: Re: [PATCH v2] lsm,ima: new LSM hook
security_kernel_module_read_file to access decompressed kernel module
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.
The patch with a few minor changes looks good:
- READDING_MODULE_CHECK -> READING_MODULE_CHECK
- Fix the enumeration name in ima_main.c
- scripts/checkpatch.pl code/comment line length has been relaxed to 100 chars,
but the section "Breaking long lines and strings" in
Documentation/process/coding-style.rst still recommends 80 characters.
There are cases where it is necessary to go over the 80 char line limit for
readability, but in general both Roberto and I prefer, as much as possible, to
limit the line length to 80 char. To detect where/when the line limit is
greater than 80 chars, use the scripts/checkpatch.pl "--max-line-length=80"
option.
After fixing the patch, please post it to linux-integrity mailing list.
--
thanks,
Mimi
Powered by blists - more mailing lists