VirtualBox from the Virtualization repository and UEFI Secure Boot kernel module signing

English Virtualization
#1

It seems that, the version 6.1.14 Oracle VirtualBox in the Virtualization repository currently doesn’t have kernel modules which have been signed for UEFI Secure Boot.

  • The affected modules are “vboxdrv”, “vboxnetadp” and “vboxnetflt” – modprobe fails with an “Operation not permitted” message.

Changing back to the Leap 15.2 update repository fixed the problem without having to roll back to a previous VirtualBox version.
[HR][/HR]Does anyone suspect that this issue needs to be flagged to the Virtualization repository maintainers?

#2

??? How exactly kernel modules are related to UEFI Secure Boot?

Modules are obviously signed:

filename:       /home/bor/tmp/./lib/modules/5.8.12-1-default/extra/vboxdrv.ko
version:        6.1.14_SUSE r140239 (0x002e0000)
...
sig_id:         PKCS#7
signer:         Virtualization OBS Project
sig_key:        C6:31:15:59:C3:47:91:38
sig_hashalgo:   sha256
signature:      1A:46:C1:1E:35:A6:F4:40:A7:01:2C:08:86:5D:3B:47:91:DF:20:BF:
        9F:62:0E:F9:F2:9B:40:AF:8B:F1:83:17:9A:DD:D4:82:E9:DF:C9:49:
        8B:94:D7:06:2E:E8:9F:9C:B6:68:E2:5C:2C:42:28:AB:74:B0:E3:62:
        89:DF:0E:90:13:B4:DB:77:80:D3:2A:F4:EC:FC:3B:0C:15:B5:A0:A5:
        6D:FB:CB:F9:E8:C1:7D:AB:77:F2:B2:5B:8B:FC:EA:E5:18:B3:56:1B:
        39:60:CD:90:BD:7C:D6:DF:8A:48:59:91:0F:B1:88:7F:F7:F1:BD:72:
        3C:EB:9E:13:37:CD:49:AA:A4:16:73:20:7F:C4:73:6D:2F:D6:33:D3:
        26:CC:8C:6B:8C:9B:26:4D:EB:22:53:5E:AB:2B:34:2F:AC:12:3A:6A:
        D3:5C:60:5D:22:58:64:76:68:3C:AC:19:49:B2:3E:61:13:0A:14:F5:
        D0:4B:EE:38:D5:9D:A0:9A:A5:0C:C9:E0:BE:02:E9:8E:FA:12:E5:61:
        3B:4C:F7:EB:5F:9E:5E:1C:C4:D1:C3:D5:F9:C6:B0:6B:11:EB:94:FB:
        F7:A3:A2:AC:AF:C4:8A:02:5E:AF:2C:5D:27:10:DD:ED:8C:1A:3E:DA:
        D6:BA:7C:9D:C9:E5:F5:A1:30:F4:D2:52:31:A6:09:A4

Each project has its own key, that is not new. You either need to manually trust all keys of every project or simply do not enforce module signature check.

#3

@dcurtisfra,
Thx for reporting, you should submit a bug to https://bugzilla.opensuse.org
Since this is not the first time the problem has happened, I suspect that Larry (or whomever) is manually signing and hasn’t automated the process.

@arvidjaar
Kernel modules like what VBox are need to be signed nowadays (things weren’t so strict years ago).
Is to verify the authenticity of the modules so that some malicious hacker doesn’t load a module and then reboot injecting malware.
Is not related to OBS projects.

An Internet search will return a number of hits, the following is from kernel.org

https://www.kernel.org/doc/html/v4.15/admin-guide/module-signing.html

TSU

#4

Hi
This is incorrect, the build service automatically signs all packages, no use interaction is required!

#5

Alas, also some hints in Forums such as Stack Overflow which indicate that, the Kernel’s signature checking should be disabled to allow the “modprobe” to successfully execute …

  • The issue is not new – I was involved in a similar issue on an embedded remotely managed system more than 10 years ago …
#6

Agreed!!! – The issue is related to the “Experimental” nature of the Virtualization repository …

#7

I think you misunderstand my post and the situation.

kernel module signing has nothing to do with OBS project signing.
Apples and Oranges.

TSU

#8

I’d strongly discourage breaking security by disabling the signature check unless there is no alternative and then the consequences carefully considered.
It’s not that difficult for the module to be signed and that’s how it should be done.

IMO,
TSU

#9

Hi
I’m not talking about project signing!! Packages and kmp’s, ok!! They are signed automatically via pesign (go peruse the build logs) and the OBS tools, there is NO user interaction at this level.

Look at the output from /sbin/modinfo for any module…

#10

If OBS actually does sign kernel modules as necessary then,
It’s curious why the signing isn’t recognized and that some procedure to disable security is recommended.

TSU

#11

Did a quick search.
As I suspected, kernel module signing is available but not enabled by default… Needs to be configured and enabled.

https://en.opensuse.org/openSUSE:Build_Service_Signer#Signing_EFI_binaries.2Fkernel_modules_for_EFI_Secure_Boot

TSU

#12

Hi
Your trying my patience, LOOK at the virtualbox build log it is quite clear that the two packages mentioned are used in the build process, it’s the default, the modules are signed!

#13

Better than relying on the build log is to read the kernel module loaded on your system.

To inspect for the existence or absence of kernel module signing,

  1. Identify your current running kernel so you know how to complete the path described in step 2
uname -a
  1. Run the following command. If the module is signed, you will see a response. If the module is unsigned, the command will return an empty response
    I’m guessing a bit what the path would be after …/kernel/ because I don’t have Virtualbox installed on a Linux box at the moment… And I’m simply showing the generic “module.ko” because you’d probably want to test several modules.
readelf -S /lib/modules/[kernel name]/kernel/virt/module.ko | grep sig.*NOTE

If the signature exists, then perhaps the signing not isn’t configured correctly.

TSU

#14

Hi
You persistence shows your ignorance, look at user arvidjaar post #2, all the module signing information is available via modinfo.


readelf -S /lib/modules/5.3.18-lp152.44-default/kernel/drivers/virt/vboxguest/vboxguest.ko | grep sig.*NOTE
<zip, nada, nothing>

/sbin/modinfo vboxguest |grep sig
sig_id:         PKCS#7
signer:         openSUSE Secure Boot CA
sig_key:        30:81:81:31:20:30:1E:06:03:55:04:03:0C:17:6F:70:65:6E:53:55:
sig_hashalgo:   sha256
signature:      45:44:28:0F:20:44:15:70:76:08:8D:A1:07:91:9C:E4:E4:F7:B8:C3:
.....
#15

Which is what the openSUSE / SUSE Build Service does by default and, openQA usually checks that, the signing has been properly and correctly applied …

  • Unfortunately, sadly, the current offering in the Experimental “Virtualization” repository slipped through the net …
#16

I preceded the sentence referring to a StackOverflow suggestion with “Alas” …

Merriam-Webster:

Alas – used to express unhappiness, pity, or concern

Oxford:

Alas – used to show you are sad or sorry

Cambridge:

Alas – used to express sadness or feeling sorry about something

Collins:

Alas – You use alas to say that you think that the facts you are talking about are sad or unfortunate.