View Issue Details

IDProjectCategoryView StatusLast Update
0008331Kali LinuxFeature Requestspublic2024-06-14 15:13
Reporterschlue Assigned To 
Status closedResolutionreopened 
Product Version2023.1 
Summary0008331: Enable IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY in kernel config

With/until kernel 6.0.0-kali6 it was possible to run kali in a secure boot ( dual boot with windows ) environment on an Alienware laptop.
Grub, kernel, initrd are signed with certificates resp. gpg.
Since kernel 6.1 this is not working any longer as starting with 6.1
are being used. This requires IMA to be setup and signed with a trusted certificate loaded during boot into the .ima keyring.
Certificate in .ima keyring either needs to be signed by a certificate in .builtin_trusted_keys or in .secondary_trusted_keys.
To get a key into .builtin_trusted_keys the kernel needs to be compiled - this I want to avoid.
To get a key into .secondary_trusted_keys IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY needs to be enabled ( so either I need to compile my own kernel which I would like to avoid or this needs to be enabled in kali kernel by default which this request is about ).

Steps To Reproduce
  • import your own certificate into efivar

  • sign kernel, grub, modules, initrd with your own certificate / gpg

  • boot in secure boot mode
    => for kernel <= 6.0.0-kali6 ( I dont know if there was a later kali version with 6.0.0; six was the latest that I tried ) the system will boot

  • try the same for kernel 6.1.0-kali9 ( or earlier ones in the 6.1 tree )
    => the boot process stops in initialramfs. Keyboard does not work.
    => boot process e.g. shows func=KEXEC_KERNEL_CHECK res=1 message
    => switching secure boot mode from deployed to audit mode and it is possible to boot the kernel without any problem ( so the kernel and initrd itself are ok )




2023-05-29 08:12

manager   ~0018042

Last edited: 2023-05-29 08:12

IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY is marked as experimental in the kernel, so I'd be reluctant to enable it.

I also think this kind of bug should better be reported on the Debian bugtracker, this is not really specific to Kali. As I understand it, it was triggered by this commit in Debian:

Moreover, there's a bug on the Debian bugtracker, it seems loosely related to this issue: This bug led to a patch that is included in the kernel 6.1.20-2kali1 and onward. Can you check if this fixes your issue, by chance? (from your description it seems that you tested 6.1.0-kali9).




2023-05-30 14:55

reporter   ~0018051

IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY is marked as experimental in the kernel, so I'd be reluctant to enable it.
I was expecting this answer and definitely understand it.

I am already on that kernel version you asked me to test.
While I was referring to the package name you referred to the version of the package.
ii linux-image-6.1.0-kali9-amd64 6.1.27-1kali1

I had a look to the bug I still do not understand why it is working for the other person.
Unfortunately the keyboard does not react when it stops in initramfs. If it wouldn't I would be able to store/save/extract the log messages collected till that stage.
As far as I understand the report the computer in the bug report does not have a TPM device while mine has. Not sure if this makes a difference here.
The more looking into it the before mentioned difference might be the difference that has an effect here.
Reading IMA_TRUSTED_KEYRING seems to be deprecated and to be used ... which results in "This option requires that all keys added to the .ima and .evm keyrings be signed by a key on the system trusted keyring."
As far as I understand "system trusted keyring" is .builtin_trusted_keys which I "can not " change.

I am happy to continue debugging but as it always stops in the initramfs I cannot have a look to what really happened. At this moment I am using my cellphone to record the output but that is also not good to read.

So it is better to report this in the debian kernel forum ?



2023-05-31 00:38

manager   ~0018054

I think on our side, we can rebuild a kernel with IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY=1 and upload it to kali-experimental. This way, you can install it and tell us if, indeed, it fixes the issue.

After that, we can open the bug in Debian.

I'll ping you back when the new kernel package is ready.



2023-05-31 01:46

manager   ~0018055

Last edited: 2023-05-31 01:46

I did more a bit more archeology in the Debian git repo for the kernel.

So the IMA config was enabled back in Apr 2017: At this time, CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY was enabled, despite being marked as experimental in the Kernel's KConfig at security/integrity/ima/Kconfig.

Then CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY was disabled, in July 2017, as in fact the config was not effective, as explained in the commit message:

Fast-forward today: all the other configs required are enabled, so I don't see any blocker to enable this feature. Cf.


To come back to the change that caused this bug report, I suppose it's due to commit that enabled CONFIG_IMA_ARCH_POLICY. This was in october 2022, before release 6.1 of the Debian kernel. It's consistent with what you said, in term of versions: for your use-case, kernel 6.0.x worked, while kernel 6.1.x didn't work anymore.



2023-05-31 09:14

manager   ~0018058

Last edited: 2023-05-31 09:15

@schlue The new kernel will be in the repo in a few hours, let's say by 14:00 UTC.

At this point, please enable the repo kali-experimental, cf.

Then run "sudo apt update" and then install the new kernel with:

sudo apt install -v -t kali-experimental '?upgradable ?source-package("linux")'

The command above will upgrade the kernel and kernel-related packages that are already installed on your system. NB: I didn't test the command, so pay attention to what gets upgraded !! What I expect is that the package linux-image-amd64 gets upgraded to 6.1.27-1kali2, along with many other kernel related packages.

If that's the case, please upgrade, reboot, check that IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY is enabled:

grep IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY /boot/config-<<your-current-version-here>>

If all of that is good, then you can then test if it fixes your issue.



2023-06-04 14:44

reporter   ~0018151

Thank you I can see IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY in the config file of the experimental kernel.



2023-06-06 04:12

manager   ~0018157

@schlue Did you have a chance to try this kernel, to see if that fixes the issue?



2023-06-15 02:09

manager   ~0018184

@schlue Too bad we don't have anymore feedback from you ! I really would like more details, like, did you try this kernel, did that work for you, and all of that. I need this feedback before I can get in touch with the Debian maintainers and ask them to enable it in the Debian kernel.



2023-06-15 20:20

reporter   ~0018186

I am sorry. I haven't had enough time yet to look into all details.
What I can say at this moment is that I see the kernel itself works.
I was expecting to already see at least one of the existing keys being mapped into the 'secondary keyring'. This is not the case.
So I need further dig into the steps that are required to create and import a new key.
I think I have an idea how this is to be done but definitely need more time.
@arnaudr, I will further test it and come back with more feedback.



2023-06-16 01:16

manager   ~0018187

Ack, good to hear, no worries and no rush, I just wanted to know if you were still around :)



2024-06-14 15:13

administrator   ~0019380

This report has been filed against an old version of Kali. We will be closing this ticket due to inactivity.

Please could you see if you are able to replicate this issue with the latest version of Kali Linux (

If you are still facing the same problem, feel free to re-open the ticket. If you choose to do this, could you provide more information to the issue you are facing, and also give information about your setup?
For more information, please read:

Issue History

Date Modified Username Field Change
2023-05-26 10:05 schlue New Issue
2023-05-29 08:12 arnaudr Note Added: 0018042
2023-05-29 08:12 arnaudr Note Edited: 0018042
2023-05-30 14:55 schlue Note Added: 0018051
2023-05-31 00:38 arnaudr Note Added: 0018054
2023-05-31 01:46 arnaudr Note Added: 0018055
2023-05-31 01:46 arnaudr Note Edited: 0018055
2023-05-31 09:14 arnaudr Note Added: 0018058
2023-05-31 09:14 arnaudr Note Edited: 0018058
2023-05-31 09:15 arnaudr Note Edited: 0018058
2023-05-31 14:52 g0tmi1k Status new => closed
2023-05-31 14:54 g0tmi1k Status closed => new
2023-05-31 14:54 g0tmi1k Resolution open => reopened
2023-06-04 14:44 schlue Note Added: 0018151
2023-06-06 04:12 arnaudr Note Added: 0018157
2023-06-15 02:09 arnaudr Note Added: 0018184
2023-06-15 20:20 schlue Note Added: 0018186
2023-06-16 01:16 arnaudr Note Added: 0018187
2024-06-14 15:13 g0tmi1k Note Added: 0019380
2024-06-14 15:13 g0tmi1k Status new => closed