* Re: [PATCH] kexec_file: ima: allow loading a kernel with its IMA signature verified
[not found] <20230711031604.717124-1-coxu@redhat.com>
@ 2023-07-12 18:31 ` Mimi Zohar
2023-07-13 17:59 ` Eric Snowberg
2023-07-14 1:46 ` Coiby Xu
0 siblings, 2 replies; 6+ messages in thread
From: Mimi Zohar @ 2023-07-12 18:31 UTC (permalink / raw)
To: Coiby Xu, linux-integrity, linux-security-module
Cc: Eric Biederman, open list:KEXEC, open list
[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@redhat.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;
> + }
>
> if (sig_enforce) {
> pr_notice("Enforced kernel signature verification failed (%d).\n", ret);
> @@ -169,12 +176,9 @@ kimage_validate_signature(struct kimage *image)
> }
>
> /*
> - * If IMA is guaranteed to appraise a signature on the kexec
> - * image, permit it even if the kernel is otherwise locked
> - * down.
> + * When both IMA and KEXEC_SIG fail in lockdown mode, reject it.
> */
> - if (!ima_appraise_signature(READING_KEXEC_IMAGE) &&
> - security_locked_down(LOCKDOWN_KEXEC))
> + if (security_locked_down(LOCKDOWN_KEXEC))
> return -EPERM;
>
> pr_debug("kernel signature verification failed (%d).\n", ret);
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] kexec_file: ima: allow loading a kernel with its IMA signature verified
2023-07-12 18:31 ` [PATCH] kexec_file: ima: allow loading a kernel with its IMA signature verified Mimi Zohar
@ 2023-07-13 17:59 ` Eric Snowberg
2023-07-14 2:29 ` Coiby Xu
2023-07-14 1:46 ` Coiby Xu
1 sibling, 1 reply; 6+ messages in thread
From: Eric Snowberg @ 2023-07-13 17:59 UTC (permalink / raw)
To: Mimi Zohar, Coiby Xu
Cc: linux-integrity@vger.kernel.org, linux-security-module,
Eric Biederman, open list:KEXEC, open list
> On Jul 12, 2023, at 12:31 PM, Mimi Zohar <zohar@linux.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@redhat.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?
>>
>> if (sig_enforce) {
>> pr_notice("Enforced kernel signature verification failed (%d).\n", ret);
>> @@ -169,12 +176,9 @@ kimage_validate_signature(struct kimage *image)
>> }
>>
>> /*
>> - * If IMA is guaranteed to appraise a signature on the kexec
>> - * image, permit it even if the kernel is otherwise locked
>> - * down.
>> + * When both IMA and KEXEC_SIG fail in lockdown mode, reject it.
>> */
>> - if (!ima_appraise_signature(READING_KEXEC_IMAGE) &&
>> - security_locked_down(LOCKDOWN_KEXEC))
>> + if (security_locked_down(LOCKDOWN_KEXEC))
>> return -EPERM;
>>
>> pr_debug("kernel signature verification failed (%d).\n", ret);
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] kexec_file: ima: allow loading a kernel with its IMA signature verified
2023-07-12 18:31 ` [PATCH] kexec_file: ima: allow loading a kernel with its IMA signature verified Mimi Zohar
2023-07-13 17:59 ` Eric Snowberg
@ 2023-07-14 1:46 ` Coiby Xu
2023-07-14 15:02 ` Mimi Zohar
1 sibling, 1 reply; 6+ messages in thread
From: Coiby Xu @ 2023-07-14 1:46 UTC (permalink / raw)
To: Mimi Zohar
Cc: linux-integrity, linux-security-module, Eric Biederman,
open list:KEXEC, open list
On Wed, Jul 12, 2023 at 02:31:43PM -0400, Mimi Zohar 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@redhat.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.
Thanks for correcting me! I thought it's already a consensus that we could use
either signature to verify a kernel image because that's what the code of
commit 29d3c1c8dfe7 has done and the code comment seems to confirm it. But if
we just read the commit message, it indeed didn't give an answer on whether x86
and ARM are only allowed to use PE-COFF signature.
>
>> ---
>> 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;
>> + }
>>
>> if (sig_enforce) {
>> pr_notice("Enforced kernel signature verification failed (%d).\n", ret);
>> @@ -169,12 +176,9 @@ kimage_validate_signature(struct kimage *image)
>> }
>>
>> /*
>> - * If IMA is guaranteed to appraise a signature on the kexec
>> - * image, permit it even if the kernel is otherwise locked
>> - * down.
>> + * When both IMA and KEXEC_SIG fail in lockdown mode, reject it.
>> */
>> - if (!ima_appraise_signature(READING_KEXEC_IMAGE) &&
>> - security_locked_down(LOCKDOWN_KEXEC))
>> + if (security_locked_down(LOCKDOWN_KEXEC))
>> return -EPERM;
>>
>> pr_debug("kernel signature verification failed (%d).\n", ret);
>
>
--
Best regards,
Coiby
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] kexec_file: ima: allow loading a kernel with its IMA signature verified
2023-07-13 17:59 ` Eric Snowberg
@ 2023-07-14 2:29 ` Coiby Xu
2023-07-14 15:50 ` Eric Snowberg
0 siblings, 1 reply; 6+ messages in thread
From: Coiby Xu @ 2023-07-14 2:29 UTC (permalink / raw)
To: Eric Snowberg
Cc: Mimi Zohar, linux-integrity@vger.kernel.org,
linux-security-module, Eric Biederman, open list:KEXEC, open list
On Thu, Jul 13, 2023 at 05:59:38PM +0000, Eric Snowberg wrote:
>
>
>> On Jul 12, 2023, at 12:31 PM, Mimi Zohar <zohar@linux.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@redhat.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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] kexec_file: ima: allow loading a kernel with its IMA signature verified
2023-07-14 1:46 ` Coiby Xu
@ 2023-07-14 15:02 ` Mimi Zohar
0 siblings, 0 replies; 6+ messages in thread
From: Mimi Zohar @ 2023-07-14 15:02 UTC (permalink / raw)
To: Coiby Xu, Paul Moore
Cc: linux-integrity, linux-security-module, Eric Biederman,
open list:KEXEC, open list
[CC'ing Paul Moore]
On Fri, 2023-07-14 at 09:46 +0800, Coiby Xu wrote:
> On Wed, Jul 12, 2023 at 02:31:43PM -0400, Mimi Zohar 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@redhat.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.
>
> Thanks for correcting me! I thought it's already a consensus that we could use
> either signature to verify a kernel image because that's what the code of
> commit 29d3c1c8dfe7 has done and the code comment seems to confirm it. But if
> we just read the commit message, it indeed didn't give an answer on whether x86
> and ARM are only allowed to use PE-COFF signature.
I'm not aware of any consensus one way or the other. Commit
29d3c1c8dfe7 continued to fail the kexec on failure, when
CONFIG_KEXEC_SIG_FORCE was enabled.
As there isn't a lockdown maintainer, Paul are you ok with this change?
>
> >
> >> ---
> >> 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;
> >> + }
> >>
> >> if (sig_enforce) {
> >> pr_notice("Enforced kernel signature verification failed (%d).\n", ret);
> >> @@ -169,12 +176,9 @@ kimage_validate_signature(struct kimage *image)
> >> }
> >>
> >> /*
> >> - * If IMA is guaranteed to appraise a signature on the kexec
> >> - * image, permit it even if the kernel is otherwise locked
> >> - * down.
> >> + * When both IMA and KEXEC_SIG fail in lockdown mode, reject it.
> >> */
> >> - if (!ima_appraise_signature(READING_KEXEC_IMAGE) &&
> >> - security_locked_down(LOCKDOWN_KEXEC))
> >> + if (security_locked_down(LOCKDOWN_KEXEC))
> >> return -EPERM;
> >>
> >> pr_debug("kernel signature verification failed (%d).\n", ret);
> >
> >
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] kexec_file: ima: allow loading a kernel with its IMA signature verified
2023-07-14 2:29 ` Coiby Xu
@ 2023-07-14 15:50 ` Eric Snowberg
0 siblings, 0 replies; 6+ messages in thread
From: Eric Snowberg @ 2023-07-14 15:50 UTC (permalink / raw)
To: Coiby Xu
Cc: Mimi Zohar, linux-integrity@vger.kernel.org,
linux-security-module, Eric Biederman, open list:KEXEC, open list
> On Jul 13, 2023, at 8:29 PM, Coiby Xu <coxu@redhat.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@linux.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@redhat.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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-07-14 15:51 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20230711031604.717124-1-coxu@redhat.com>
2023-07-12 18:31 ` [PATCH] kexec_file: ima: allow loading a kernel with its IMA signature verified Mimi Zohar
2023-07-13 17:59 ` Eric Snowberg
2023-07-14 2:29 ` Coiby Xu
2023-07-14 15:50 ` Eric Snowberg
2023-07-14 1:46 ` Coiby Xu
2023-07-14 15:02 ` Mimi Zohar
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).