linux-kernel - Re: [PATCH] kexec_file: ima: allow loading a kernel with its IMA signature verified

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4d6t456sswt66tnpzysxuu2wmlgkmlww3elhdsf4fxzejbroza@qig3hahn5paq>
Date:   Fri, 14 Jul 2023 10:29:56 +0800
From:   Coiby Xu <coxu@...hat.com>
To:     Eric Snowberg <eric.snowberg@...cle.com>
Cc:     Mimi Zohar <zohar@...ux.ibm.com>,
        "linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>,
        linux-security-module <linux-security-module@...r.kernel.org>,
        Eric Biederman <ebiederm@...ssion.com>,
        "open list:KEXEC" <kexec@...ts.infradead.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] kexec_file: ima: allow loading a kernel with its IMA
 signature verified

On Thu, Jul 13, 2023 at 05:59:38PM +0000, Eric Snowberg wrote:
>
>
>> On Jul 12, 2023, at 12:31 PM, Mimi Zohar <zohar@...ux.ibm.com> wrote:
>>
>> [Cc'ing the LSM mailing list.]
>>
>> On Tue, 2023-07-11 at 11:16 +0800, Coiby Xu wrote:
>>> When IMA has verified the signature of the kernel image, kexec'ing this
>>> kernel should be allowed.
>>>
>>> Fixes: af16df54b89d ("ima: force signature verification when CONFIG_KEXEC_SIG is configured")
>>> Signed-off-by: Coiby Xu <coxu@...hat.com>
>>
>> The original commit  29d3c1c8dfe7 ("kexec: Allow kexec_file() with
>> appropriate IMA policy when locked down") was not in lieu of the PE-
>> COFF signature, but allowed using the IMA signature on other
>> architectures.
>>
>> Currently on systems with both PE-COFF and IMA signatures, both
>> signatures are verified, assuming the file is in the IMA policy.  If
>> either signature verification fails, the kexec fails.
>>
>> With this patch, only the IMA signature would be verified.
>>
>>> ---
>>> kernel/kexec_file.c | 14 +++++++++-----
>>> 1 file changed, 9 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
>>> index 881ba0d1714c..96fce001fbc0 100644
>>> --- a/kernel/kexec_file.c
>>> +++ b/kernel/kexec_file.c
>>> @@ -162,6 +162,13 @@ kimage_validate_signature(struct kimage *image)
>>> 	ret = kexec_image_verify_sig(image, image->kernel_buf,
>>> 				     image->kernel_buf_len);
>>> 	if (ret) {
>>> +		/*
>>> +		 * If the kernel image already has its IMA signature verified, permit it.
>>> +		 */
>>> +		if (ima_appraise_signature(READING_KEXEC_IMAGE)) {
>>> +			pr_notice("The kernel image already has its IMA signature verified.\n");
>>> +			return 0;
>>> +		}
>
>The issue I see here is ret could be many things, for example it could be
>-EKEYREJECTED, meaning it was contained on a revocation list.  With this patch
>the revocation could be overruled if the image was IMA signed with a different
>key.  Do we really want to add the ability to overrule a revocation?

Thanks for raising the concern! I haven't thought about this case of the
key being in a revocation list. If the IMA signature comes from a
distribution, the distribution should also blocklist the IMA key when
the PE-COFF signature key is added to the revocation list. If the IMA
signature is from an end-user, I think the user wants to pass the
verification in this case.

Or how about only allowing IMA signature when EFI runtime services are
disabled?  Another reason I am yet to add to the commit message is a
real-time kernel currently disables EFI runtime services for latency
issues so it can't access the MOK keys to verify the PECOFF signature.