Kernel module signing not persistent after rebooting Ubuntu host

Discussions related to using VirtualBox on Linux hosts.
fth0
Volunteer
Posts: 5668
Joined: 14. Feb 2019, 03:06
Primary OS: Mac OS X other
VBox Version: PUEL
Guest OSses: Linux, Windows 10, ...
Location: Germany

Re: Kernel module signing not persistent after rebooting Ubuntu host

Post by fth0 »

I'll try and address some of your questions implicitly:

Code: Select all

:/lib/modules/5.4.0-139-generic/misc$ ll
insgesamt 656
drwxr-xr-x 2 root root   4096 Feb 15 17:09 ./
drwxr-xr-x 6 root root   4096 Feb 15 17:09 ../
-rw-r--r-- 1 root root 595731 Feb 15 17:09 vboxdrv.ko
-rw-r--r-- 1 root root  17571 Feb 15 17:09 vboxnetadp.ko
-rw-r--r-- 1 root root  44227 Feb 15 17:09 vboxnetflt.ko
On Debian/Ubuntu/Mint hosts, VirtualBox uses the misc folder. On February 15th, this host had the last Linux kernel update, and it was rebooted at least once a week since then.

Code: Select all

:/lib/modules/5.4.0-139-generic/misc$ modinfo vboxdrv.ko
filename:       /lib/modules/5.4.0-139-generic/misc/vboxdrv.ko
version:        6.1.42 r155177 (0x00320000)
license:        GPL
description:    Oracle VM VirtualBox Support Driver
author:         Oracle Corporation
srcversion:     E85989480CD9E7B95D80254
depends:        
retpoline:      Y
name:           vboxdrv
vermagic:       5.4.0-139-generic SMP mod_unload modversions 
sig_id:         PKCS#7
signer:         mint Secure Boot Module Signature key
sig_key:        62:6A:91:71:3B:BD:B4:C9:44:F3:C3:55:4F:81:C6:54:DD:90:F7:47
sig_hashalgo:   sha512
signature:      4F:F5:07:E8:FA:86:85:42:5C:9E:99:34:37:3F:FE:B0:3E:9A:01:89:
                [...]
When the Linux Mint 20 (based on Ubuntu 20.04 LTS) host OS was installed in 2020, Secure Boot was already enabled (because of Windows 10 being pre-installed on the host) and the MOK was automatically created. I don't recall if I still had to do the "special procedure" manually, since Linux Mint got user-friendlier earlier than Ubuntu in that regard. VirtualBox uses kmodsign to sign its kernel modules after building them.

I could envision that using your own MOK could play a role here. I'd suggest to use set -x before manually executing vboxdrv.sh as a simple debugging tool. ;)
milverton
Posts: 48
Joined: 17. Apr 2022, 22:25

Re: Kernel module signing not persistent after rebooting Ubuntu host

Post by milverton »

Thank you, fth0. There's plenty for me to be working through with that information. I didn't understand why a MOK seemed needed, so I'm kind of with your observation on that. More in due course.
milverton
Posts: 48
Joined: 17. Apr 2022, 22:25

Re: Kernel module signing not persistent after rebooting Ubuntu host

Post by milverton »

Well, the problem is fixed now and everything is working well. The timestamps and sizes of the /misc/vbox*.ko files do not change any more on re-boot - so the changes there - toggling to and fro - were indeed a reliable clue that something was amiss.

One of the things that had confused me, with hindsight, is that an MOK key and certificate are stil needed, but they are created in the course of following the instructions which appear one-time-only during the installation of VirtualBox. I re-installed VirtualBox; for full disclosure I upgraded from version 6.1.40 to 6.1.42, being motivated to make that change by observing what version your code snippets revealed, ftho. After uninstalling the old version I cleaned up various things including renaming the /vsar/lib/shim-signed/mok directory and also the /usr/src/linux-headers-$(uname -r)/certs directory, to have the freshest possible start. (The latter did not get re-created with the new install.) I didn't use "purge", but rather ran as root "apt-get remove virtualbox*" - the asterisk being significant.

For the re-install I used sudo apt install ./Downloads/virtualbox-6.1_6.1.42-155177~Ubuntu~jammy_amd64.deb. There were clear, although still a bit cryptic, instructions in the terminal window; but I think they appear detailed there to an extent which I had either missed before or not paid sufficient attention to. In fact, I missed them there as well, instead skipping past them to the last instruction, namely to manually re-boot and run sudo rcvboxdrv setup. Then, in due course, the same instructions appeared again, but they were somehow clearer this time. They prompted to do manually more or less what I had previously tried to do before creating this topic: the exact terminal commands were given this time, though, inspiring greater confidence. I copied them to a text file for reference. Four commands had to be done manually, with the last being reboot. During the part when questions were asked to make the certificate, only one field turned out to be needed: the one labeled "Common Name", and pretty much anything distinctive could be entered there. Between the 3rd and 4th commands came the "special procedure part 1", involving entering an 8-digit temporary password, and after the re-boot (the second) came the "special procedure part 2". This time, when the command sudo rcvboxdrv setup was run, there were no errors and the modules were signed without any excitement. Confirmation was given by running sudo modinfo /lib/modules/$(uname -r)/misc/vboxdrv.ko.

Since this had been an upgrade, there was a new extension pack download and install in conjunction with the VirtualBox Manager; and guest additions virtual disk to add to, and run on, the VMs individually.

Something that still puzzles me, though, is that somehow I was not able to make use of a trusted public key which was enrolled in the kernel by Cononical (Ubuntu) specifically labeled for signing kernel modules. I had noticed, fth0, that your modinfo output revealed that your key was a trusted public key from Mint for the same purpose, but I couldn't replicate the Canonical equivalent outcome.
fth0
Volunteer
Posts: 5668
Joined: 14. Feb 2019, 03:06
Primary OS: Mac OS X other
VBox Version: PUEL
Guest OSses: Linux, Windows 10, ...
Location: Germany

Re: Kernel module signing not persistent after rebooting Ubuntu host

Post by fth0 »

Thanks for reporting back! :)
milverton wrote:Something that still puzzles me, though, is that somehow I was not able to make use of a trusted public key which was enrolled in the kernel by Cononical (Ubuntu) specifically labeled for signing kernel modules.
That's because you perhaps don't yet understand how asymmetric cryptography works, and/or you don't yet know that there are two key pairs involved:

Canonical created a key pair, consisting of a private key and a public key. The private key is in their company ("safe") and used to sign the Linux kernel modules when they're built there. The public key is installed on your host and everybody can verify the signatures on your host.

When Ubuntu/Mint are installed, another key pair (Machine Owner Key, MOK) is created on the host, and the private public key is stored in the TPM/UEFI MokManager as part of Secure Boot. This is what the "special procedure" (your term ;)) is needed for. When some software (like VirtualBox) builds their own kernel modules, it can sign them using the private key part of the MOK, and anybody can verify the signatures on your host using the public key part of the MOK, which is saved in /var/lib/shim-signed/mok.
Last edited by fth0 on 17. Mar 2023, 00:01, edited 1 time in total.
milverton
Posts: 48
Joined: 17. Apr 2022, 22:25

Re: Kernel module signing not persistent after rebooting Ubuntu host

Post by milverton »

I've found there are a number of places to get help understanding this. One of them is https://www.encryptionconsulting.com/sy ... re-secure/. About a third of the way down that page I've found this, in discussing asymmetric key pairs:

"The public and private keys are computed simultaneously [my emphasis], using the same mathematical operation..." and "Using a private key, we can find the public key, but the private key cannot be obtained using the public key."

So, to understand that your modinfo names "mint Secure Boot Module Signature key" as the signer, would I be correct to think that the installation of VirtualBox on your machine was obtained from a Linux Mint repository, whereas my installation was obtained independently of Ubuntu's repository - namely from VirtualBox directly - and that left me with the need to generate my own asymmetric key pair?
fth0
Volunteer
Posts: 5668
Joined: 14. Feb 2019, 03:06
Primary OS: Mac OS X other
VBox Version: PUEL
Guest OSses: Linux, Windows 10, ...
Location: Germany

Re: Kernel module signing not persistent after rebooting Ubuntu host

Post by fth0 »

milverton wrote:So, to understand that your modinfo names "mint Secure Boot Module Signature key" as the signer, would I be correct to think that the installation of VirtualBox on your machine was obtained from a Linux Mint repository
No. The mint Secure Boot Module Signature key is the MOK: ;)

Code: Select all

$ openssl x509 -inform DER -in /var/lib/shim-signed/mok/MOK.der -text -noout | grep mint
        Issuer: CN = mint Secure Boot Module Signature key
        Subject: CN = mint Secure Boot Module Signature key
milverton
Posts: 48
Joined: 17. Apr 2022, 22:25

Re: Kernel module signing not persistent after rebooting Ubuntu host

Post by milverton »

OK - but that exact wording - did you enter it in the "Common Name" field when that was presented, or did your installation propose that wording without your help?

Here's what I have - and I know that the "Common Name" in this case came 100% from me! Are you suggesting I could somehow have ended up with a phrase such as "ubuntu Secure Boot Module Signature key" - other than by entering it myself? (I'm sorry if it seems I'm prying: that's not the case; but I'd just like to understand the difference! The VirtualBox download page points to the exact same installation download for Linux Mint as for Ubuntu, doesn't it? - so we'd both have started from the same place, wouldn't we?)

Code: Select all

$ openssl x509 -inform DER -in /var/lib/shim-signed/mok/MOK.der -text -noout | grep bri
        Issuer: CN = bright_future
        Subject: CN = bright_future
milverton
Posts: 48
Joined: 17. Apr 2022, 22:25

Re: Kernel module signing not persistent after rebooting Ubuntu host

Post by milverton »

Or is there a way to request a key pair from the distro - Linux Mint or Ubuntu, respectively - before running the installation? - and you did things in that order, whereas I didn't?
fth0
Volunteer
Posts: 5668
Joined: 14. Feb 2019, 03:06
Primary OS: Mac OS X other
VBox Version: PUEL
Guest OSses: Linux, Windows 10, ...
Location: Germany

Re: Kernel module signing not persistent after rebooting Ubuntu host

Post by fth0 »

milverton wrote:OK - but that exact wording - did you enter it in the "Common Name" field when that was presented, or did your installation propose that wording without your help?
The latter, and I don't remember if I got a chance to change the CN. Here's what I did:

I got a new notebook with Windows 10 pre-installed and Secure Boot enabled. In Windows 10, I shrinked the Windows partition to make room for a dual-boot Linux installation. Then I booted the notebook from an external SSD with the Linux Mint installer, started the latter, chose to keep Secure Boot at some point during the installation, perhaps (*) chose a temporary password, the installer created the MOK, rebooted the notebook, the UEFI BIOS MokManager perhaps (*) asked for the temporary password and installed the MOK into the TPM/UEFI.

(*) I've done this several times in the last 10 years on different computers with various Ubuntu and Linux Mint versions, but I'm not sure if I had to choose and use a temporary password the last time.

Some days later, I added the Oracle VirtualBox repository to APT on Linux Mint and installed VirtualBox with a command like sudo apt install virtualbox-6.1.
milverton wrote:The VirtualBox download page points to the exact same installation download for Linux Mint as for Ubuntu, doesn't it?
Yes, there is no extra Linux Mint version of VirtualBox.
milverton wrote:so we'd both have started from the same place, wouldn't we?
Yes, with the exception that in my case, Secure Boot and the MOK were in place before I installed VirtualBox the first time.
milverton wrote:Or is there a way to request a key pair from the distro - Linux Mint or Ubuntu, respectively - before running the installation? - and you did things in that order, whereas I didn't?
My description above should have covered those questions. Don't hesitate to ask if you have further questions. ;)
Last edited by fth0 on 17. Mar 2023, 00:03, edited 1 time in total.
milverton
Posts: 48
Joined: 17. Apr 2022, 22:25

Re: Kernel module signing not persistent after rebooting Ubuntu host

Post by milverton »

Thank you again, fth0.
... in my case, Secure Boot and the MOK were in place before I installed VirtualBox the first time
If my limited understanding is any guide, the MOK you're referring to here is the one needed to enable Linux Mint to start with Secure Boot enabled - isn't it? - and it would have a "build time" label of some kind (referring to the installation of Linux Mint), wouldn't it?

... whereas the MOK needed to enable VirtualBox to run under Linux Mint with Secure Boot enabled would be a different MOK, and that's the one with the label or CN which includes the phrase "mint Secure Boot Module Signature key" (or something else, as discussed), as a way of identifying it if ever needed.

Admittedly, with the subject of the topic solved, I'm dancing a bit around its perimeter now; so to recap what others with the same original symptom might wish to know I think the following sums it up - but please correct this if it doesn't look right to you:
  • keep Secure Boot enabled throughout all these steps;
  • to be extra cautious, temporarily rename the VirtualBox VMs directory;
  • uninstall VirtuaBox as root, using "apt-get remove virtualbox*" - the asterisk being significant (but don't use "purge");
  • delete (or at least re-name) the mok directory, which is at /var/lib/shim-signed, and also the misc directory, if still present, which is at /usr/lib/modules/$(uname -r);
  • it's probably best at this point to re-boot the machine;
  • cd to the directory where VirtualBox has been downloaded, and re-install VirtualBox as normal using sudo in the terminal, and in so doing pay attention to the part of the process where the following appears in the terminal window "System is running in Secure Boot mode, however your distribution does not provide tools for automatic generation of keys needed for modules signing;
  • possibly using a separate terminal window while leaving the first one open, copy, paste, and execute in turn each one of the "manual" steps given there - only one of the fields presented is a "must" to contain something, namely the "CN" or "Common Name" field - and a temporary password of 8 digits is going to be requested;
  • after reboot - which is necessary to activate the MOK Manager and enroll the new MOK - and noting that the defaults presented at that stage will whisk you right past the one-time option of doing so if you're not paying attention(!) - run sudo rcvboxdrv setup, which should confirm that the kernel module files get signed with no issues;
  • the timestamps and file sizes of the module .ko files should not change after that, indicating that the signing of the module files is now "persistent" - to verify this it will be necessary to reboot and check at least one of the timestamps;
  • reverse the earlier re-naming of the VirtualBox VMs directory;
  • start VirtualBox. It might be necessary to install the Extension Pack as/if prompted by the VirtualBox Manager; and to make the Guest Additions virtual optical disk available to VMs individually.
fth0
Volunteer
Posts: 5668
Joined: 14. Feb 2019, 03:06
Primary OS: Mac OS X other
VBox Version: PUEL
Guest OSses: Linux, Windows 10, ...
Location: Germany

Re: Kernel module signing not persistent after rebooting Ubuntu host

Post by fth0 »

milverton wrote:If my limited understanding is any guide, the MOK you're referring to here is the one needed to enable Linux Mint to start with Secure Boot enabled - isn't it? - and it would have a "build time" label of some kind (referring to the installation of Linux Mint), wouldn't it?

... whereas the MOK needed to enable VirtualBox to run under Linux Mint with Secure Boot enabled would be a different MOK, and that's the one with the label or CN which includes the phrase "mint Secure Boot Module Signature key" (or something else, as discussed), as a way of identifying it if ever needed.
I'm sorry, but you're still on the wrong path.

There is only one MOK, and it's not the key used by Ubuntu/Mint to sign its own kernel modules at their own site. To see it for yourself, look at modinfo hid (or use any other kernel module instead of hid). Both the Ubuntu/Mint key and the MOK are used during the Secure Boot procedure to verify the kernel modules' signatures. The former is used for the kernel modules installed via binary packages, the latter is used for kernel modules built and signed on the Machine Owner's (your) computer.

You might be interested in reading SecureBoot on the Ubuntu Wiki, which explains the whole topic with more details than I'm willing to repeat here. ;)

PS: Following my own advice to read the SecureBoot page on the Ubuntu Wiki, I noticed that I was slightly wrong: The private key part of the MOK is not stored in the TPM, but only on disk, and the public key part of the MOK is stored in the UEFI MokManager. I've corrected my previous posts accordingly.
milverton
Posts: 48
Joined: 17. Apr 2022, 22:25

Re: Kernel module signing not persistent after rebooting Ubuntu host

Post by milverton »

I will read the article you cite, and it will be for the umpteenth time - so that just reinforces that I can be a slow learner! I think where I misspoke was in referring to the OS installation key pair as a MOK key pair, whereas it is still a key pair, just not of the "MO" type.

It seems silly with hindsight, but I think what got me off the rails - which reflects more on the way my mind works as a beginning student than anything else - was the appearance of the word "mint" together with the other rather "factory-type words" comprising the "signer" as revealed in your modinfo output.

I feel my original topic has been given a good airing and a good solution found - with much help from you; and if it helps anyone else, great! Thank you so much, fth0.

P.S. in response to your P.S:
The thing that changed my understanding the most was the sentence I quoted earlier on the webpage https://www.encryptionconsulting.com/sy ... re-secure/ which says "The public and private keys are computed simultaneously [my emphasis], using the same mathematical operation...". Somehow, with talk about the two keys in the pair - which you are referring to as "parts" - being stored in different places, before that awakening I missed the point that they are inextricably linked from the time they are simultaneoulsy created: and, it bears repeating, created by the same mathematical operation!

I think I probably went through creating MOK pairs (with enrolling) about a dozen times before I started this topic. I changed subtle things each time, but that wasn't to be the solution: nary a time were they "persistent" after re-boot; and the extra step described in my early posts was always needed. The other awakening, it seems now with hindsight, was realizing that the installation of VirtualBox takes different "switches", to borrow a term from railroads, depending on whether Secure Boot is enabled when it is installed; and it seems just about impossible to convert a non-Secure-Boot installation of VirtualBox to a Secure-Boot installation without doing the installation over from the beginning. That's because - correct me if I'm mistaken - the prompts needed to make sure things are done correctly for Secure Boot don't appear if the installation is done with Secure Boot disabled.
fth0
Volunteer
Posts: 5668
Joined: 14. Feb 2019, 03:06
Primary OS: Mac OS X other
VBox Version: PUEL
Guest OSses: Linux, Windows 10, ...
Location: Germany

Re: Kernel module signing not persistent after rebooting Ubuntu host

Post by fth0 »

milverton wrote:I will read the article you cite, and it will be for the umpteenth time - so that just reinforces that I can be a slow learner!
Don't take it too hard! The article covers a lot of different aspects and it's easy to get overwhelmed. To understand the details, it helps to have a lot of background knowledge, most of which I accumulated over some decades (asymmetric cryptography, keys, certificates, signing and verifying, UEFI BIOS, security principles, ...).
milverton wrote:The other awakening, it seems now with hindsight, was realizing that the installation of VirtualBox takes different "switches", to borrow a term from railroads, depending on whether Secure Boot is enabled when it is installed; and it seems just about impossible to convert a non-Secure-Boot installation of VirtualBox to a Secure-Boot installation without doing the installation over from the beginning. That's because - correct me if I'm mistaken - the prompts needed to make sure things are done correctly for Secure Boot don't appear if the installation is done with Secure Boot disabled.
I don't know. I'd expect vboxdrv.sh to sign the VirtualBox kernel modules if it finds the MOK, independent of Secure Boot being enabled or not. If the user had it disabled and enabled it later, it would simply work. But I haven't verified this.
fth0
Volunteer
Posts: 5668
Joined: 14. Feb 2019, 03:06
Primary OS: Mac OS X other
VBox Version: PUEL
Guest OSses: Linux, Windows 10, ...
Location: Germany

Re: Kernel module signing not persistent after rebooting Ubuntu host

Post by fth0 »

You were right, the VirtualBox kernel modules get only signed if Secure Boot is enabled.

PS: You seem to have removed your post. Don't let the moderators catch you for forum vandalism. ;)
milverton
Posts: 48
Joined: 17. Apr 2022, 22:25

Re: Kernel module signing not persistent after rebooting Ubuntu host

Post by milverton »

True - I did delete my post questioning the very point you are now granting to me! That's because I decided to take more time out to study the Ubuntu Wiki reference you suggested, and early on in doing so I came to the conclusion that you were the one who was right! Not sure where that leaves us, but since you responded to that post I'm replacing its contents here: (That puts it out-of-sequence, though)
I don't know. I'd expect vboxdrv.sh to sign the VirtualBox kernel modules if it finds the MOK, independent of Secure Boot being enabled or not.
Attached is a screenshot showing six occurrences of "Secure Boot" in the file vboxdrv.sh (to see all six scroll to the bottom) - and in particular, the words I quoted in my bullet-point list of steps in an earlier post, "System is running in Secure Boot mode, however your distribution..." I agree with the aim of what you are suggesting, but I don't think it works that way; if only because enrolling a MOK (if one needs to be created) can pretty much only be done with Secure Boot enabled - and it would be confusing to create one and not enroll it.
Attachments
image_1.png
image_1.png (110.71 KiB) Viewed 2350 times
Post Reply