Bug 1702844 - Signing kernel modules with own key isn't correctly validated
Summary: Signing kernel modules with own key isn't correctly validated
Keywords:
Status: CLOSED DUPLICATE of bug 1701096
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 29
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-04-24 23:06 UTC by Jan Hugo Prins
Modified: 2019-04-25 01:39 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-04-25 01:39:21 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Complete kernel log (148.63 KB, text/plain)
2019-04-24 23:06 UTC, Jan Hugo Prins
no flags Details

Description Jan Hugo Prins 2019-04-24 23:06:24 UTC
Created attachment 1558425 [details]
Complete kernel log

1. Please describe the problem:

On a system with UEFI boot and signed kernel modules I have created my own key and certificate to sign 3rd party kernel modules (VMWARE vmmon and vmnet) so they are properly loaded into the kernel. Starting at kernel version 5.0.8-200.fc29.x86_64 the signature is not recognized anymore, although the modules are signed and the key is imported into the running kernel. With version 5.0.7-200 this worked fine.

In the past I have used the following documentation to create my setup and to install the key into the kernel UEFI structures. 

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Kernel_Administration_Guide/sect-signing-kernelhttps://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Kernel_Administration_Guide/sect-signing-kernel-modules-for-secure-boot.html#table-kernel-module-authentication-requirements-for-loading-modules-for-secure-boot.html#table-kernel-module-authentication-requirements-for-loading

To validate that the module is actually signed correctly I use the script from the following URL: 

https://unix.stackexchange.com/questions/493170/how-to-verify-a-kernel-module-signature

[root@capetown bin]# ./checkmodsig.pl ./public_key.pem `modinfo -n vmmon`
OK /lib/modules/5.0.8-200.fc29.x86_64/misc/vmmon.ko

[root@capetown bin]# ./checkmodsig.pl ./public_key.pem `modinfo -n vmnet`
OK /lib/modules/5.0.8-200.fc29.x86_64/misc/vmnet.ko

During boot the kernel gives the following messages:

First the certificates are being loaded into the kernel:

[    1.259532] integrity: Loading X.509 certificate: UEFI:db
[    1.259548] integrity: Loaded X.509 cert 'Dell Inc. UEFI DB: 5ddb772dc880660055ba0bc131886bb630a639e7'
[    1.259548] integrity: Loading X.509 certificate: UEFI:db
[    1.259564] integrity: Loaded X.509 cert 'Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4'
[    1.259565] integrity: Loading X.509 certificate: UEFI:db
[    1.259579] integrity: Loaded X.509 cert 'Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53'
[    1.259748] integrity: Loading X.509 certificate: UEFI:MokListRT
[    1.260205] integrity: Loaded X.509 cert 'BetterBe B.V.: Infra: 021af4a0a18dc92d12b96f977a7d77e92c976c85'
[    1.260205] integrity: Loading X.509 certificate: UEFI:MokListRT
[    1.260334] integrity: Loaded X.509 cert 'Fedora Secure Boot CA: fde32599c2d61db1bf5807335d7b20e4cd963b42'

When I try to load the module:

[ 1675.543495] PKCS#7 signature not signed with a trusted key

The result is that the module is not loaded into the kernel.


2. What is the Version-Release number of the kernel:

5.0.8-200


3. Did it work previously in Fedora? If so, what kernel version did the issue
   *first* appear?  Old kernels are available for download at
   https://koji.fedoraproject.org/koji/packageinfo?packageID=8 :

5.0.8-200


4. Can you reproduce this issue? If so, please provide the steps to reproduce
   the issue below:

I followed the steps in the RedHat documentation for signing kernel modules. 



5. Does this problem occur with the latest Rawhide kernel? To install the
   Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by
   ``sudo dnf update --enablerepo=rawhide kernel``:



6. Are you running any modules that not shipped with directly Fedora's kernel?:

vmmon and vmnet needed by vmware-workstation-prof.

7. Please attach the kernel logs. You can get the complete kernel log
   for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the
   issue occurred on a previous boot, use the journalctl ``-b`` flag.

Comment 1 Jan Hugo Prins 2019-04-24 23:31:19 UTC
Just tested the latest rawhide kernel and the problem is also in this kernel.
[root@capetown bin]# ./checkmodsig.pl ./public_key.pem `modinfo -n vmnet`
OK /lib/modules/5.1.0-0.rc5.git2.1.fc31.x86_64/misc/vmnet.ko
[root@capetown bin]# ./checkmodsig.pl ./public_key.pem `modinfo -n vmmon` 
OK /lib/modules/5.1.0-0.rc5.git2.1.fc31.x86_64/misc/vmmon.ko
[root@capetown bin]# uname -r
5.1.0-0.rc5.git2.1.fc31.x86_64

[root@capetown bin]# modprobe vmmon
modprobe: ERROR: could not insert 'vmmon': Operation not permitted
[root@capetown bin]# modprobe vmnet
modprobe: ERROR: could not insert 'vmnet': Operation not permitted


[    3.464627] integrity: Loading X.509 certificate: UEFI:db
[    3.464658] integrity: Loaded X.509 cert 'Dell Inc. UEFI DB: 5ddb772dc880660055ba0bc131886bb630a639e7'
[    3.464659] integrity: Loading X.509 certificate: UEFI:db
[    3.464736] integrity: Loaded X.509 cert 'Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4'
[    3.464737] integrity: Loading X.509 certificate: UEFI:db
[    3.464760] integrity: Loaded X.509 cert 'Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53'
[    3.465058] integrity: Loading X.509 certificate: UEFI:MokListRT
[    3.465508] integrity: Loaded X.509 cert 'BetterBe B.V.: Infra: 021af4a0a18dc92d12b96f977a7d77e92c976c85'
[    3.465509] integrity: Loading X.509 certificate: UEFI:MokListRT
[    3.465664] integrity: Loaded X.509 cert 'Fedora Secure Boot CA: fde32599c2d61db1bf5807335d7b20e4cd963b42'

Comment 2 Jeremy Cline 2019-04-25 01:39:21 UTC
Hi,

It should be fixed in 5.1.0-0.rc6.git1.1.fc31.x86_64, with fixes on their way for stable.

*** This bug has been marked as a duplicate of bug 1701096 ***


Note You need to log in before you can comment on or make changes to this bug.