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: https://salsa.debian.org/kernel-team/linux/-/commit/b44269f39234630ba08114bd48ece5e9df364841

Moreover, there's a bug on the Debian bugtracker, it seems loosely related to this issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030200. 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).

Thanks!

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 https://cateee.net/lkddb/web-lkddb/IMA_TRUSTED_KEYRING.html IMA_TRUSTED_KEYRING seems to be deprecated and https://cateee.net/lkddb/web-lkddb/INTEGRITY_TRUSTED_KEYRING.html 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 ?

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.

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: https://salsa.debian.org/kernel-team/linux/-/commit/f3c3de0f. 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: https://salsa.debian.org/kernel-team/linux/-/commit/d6692c5a

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

$ grep -E 'SYSTEM_TRUSTED_KEYRING|SECONDARY_TRUSTED_KEYRING|INTEGRITY_ASYMMETRIC_KEYS' /boot/config-6.1.0-8-amd64 
CONFIG_INTEGRITY_ASYMMETRIC_KEYS=y
CONFIG_SYSTEM_TRUSTED_KEYRING=y
CONFIG_SECONDARY_TRUSTED_KEYRING=y

To come back to the change that caused this bug report, I suppose it's due to commit https://salsa.debian.org/kernel-team/linux/-/commit/b44269f3 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.

@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. https://www.kali.org/docs/general-use/kali-linux-sources-list-repositories/#enabling-kali-additional-branches

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

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

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:

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

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

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

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

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

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.

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