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] [day] [month] [year] [list]

Date:   Fri, 14 Jul 2023 15:50:55 +0000
From:   Eric Snowberg <eric.snowberg@...cle.com>
To:     Coiby Xu <coxu@...hat.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 Jul 13, 2023, at 8:29 PM, Coiby Xu <coxu@...hat.com> wrote:
> 
> 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.

Correct, the IMA signature should be on the revocation list in this case.  
However, the embedded signature in the kernel doesn’t have to be the 
same as the IMA signature in the extended attribute.  If they don’t match 
up, IMA could be used as a bypass mechanism to kexec a kernel that 
shouldn’t load.

> 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.

Possibly? On a UEFI system, the IMA signature on a kernel is ignored during 
boot, GRUB2 doesn’t have a way to validate it.  If GRUB2 is booting a kernel 
on a system with EFI runtime services disabled, not only will you be missing 
the MOK keys, but you will be missing the MOKX and DBX too.