View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0008331||Kali Linux||[All Projects] Feature Requests||public||2023-05-26 10:05||2023-06-06 04:12|
|Target Version||Fixed in Version|
|Summary||0008331: Enable IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY in kernel config|
|Description||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 )
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: 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).
> 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.
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: 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
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.
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. 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:
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.
||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?|
|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||View Revisions|
|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||View Revisions|
|2023-05-31 09:14||arnaudr||Note Added: 0018058|
|2023-05-31 09:14||arnaudr||Note Edited: 0018058||View Revisions|
|2023-05-31 09:15||arnaudr||Note Edited: 0018058||View Revisions|
|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|