Install VirtualBox while keeping Secure Boot

Question

I am trying to install VirtualBox on Ubuntu 16.04 while keeping Secure Boot. When I installed it though Synaptic, I was asked to remove the SecureBoot, I said No.

I followed these instructions: Could not load 'vboxdrv' after upgrade to Ubuntu 16.04 (and I want to keep secure boot) and https://stegard.net/2016/10/virtualbox-secure-boot-ubuntu-fail/ Both are pretty much the same (I left the MOK files in the /root directory like in the second link). All seems to work fine, I rebooted, put my password again, rebooted. All good

But then when I try to use VirtualBox it still wont work. If I run it from terminal I get:

WARNING: The character device /dev/vboxdrv does not exist.
     Please install the virtualbox-dkms package and the appropriate
     headers, most likely linux-headers-generic.

     You will not be able to start VMs until this problem is fixed.

But those two packages are already installed and up-to-date.

On of the comments in the top answer of the other post says to reinstall virtualbox-dkms before following those instructions. I tried, and same result.

I tried the answer here: Problem with the installation of VirtualBox Which prompts me again to ask if I want to disable the Secure Boot, to which I say No, and back to square one.

If I run modprobe I get: modprobe: ERROR: could not insert 'vboxdrv': Required key not available

Any idea on how to get VirtualBox to work with the SecureBoot enabled (please refrain from telling me to remove it...)?

thanks

Solution 1

I have not tried either of those procedures. I do, however, do this in a different way -- but it's a very tedious method. This description will make it seem easier than that because I refer to a big page I've written that covers the worst of the tedious parts. My procedure is:

1. Take control of Secure Boot -- In my case, I've configured my computer so that I embed my own Secure Boot public key in the firmware. This way I don't need to use Shim or MOKs. I've removed Microsoft's keys from and added my own and Canonical's keys to the computer on which I use this procedure, but you can set yours up with whatever keys you like. The critical part for the purposes of your question is that you must include a key that you generate, with a private key that you retain to make it work. You'll also need keys used to sign standard components -- Canonical's key, Microsoft's public marketplace key, or both. If you dual-boot with Windows, you'll need the public key for the one Microsoft uses to sign its own boot loader. See this page of mine for all the gory details -- but be aware that this is a tedious and finicky procedure, so you may spend quite a while getting this part working. Note that most UEFIs make it pretty easy to restore the standard key set, so the risk involved in trying this procedure is low.
2. Sign the VirtualBox modules -- The next step is to sign the VirtualBox kernel modules. This is done in pretty much the same way as the pages to which you've linked describe; however, I have a script to help automate this process (see below).
3. Load the VirtualBox module -- After signing the modules, they must be loaded. This should happen automatically on reboot; but if you want to use VirtualBox without rebooting, you must explicitly use modprobe for each of the modules (vboxdrv, vboxnetflt, vboxpci, and vboxnetadp).
4. Repeat steps 2-3 after every kernel update -- After a kernel update, steps #2 and #3 must be repeated.

For convenience, I've written a script to do steps #2 and #3 in one command. I call it sign-vbox. Here it is:

#!/bin/bash
# sign-vbox script, copyright (c) 2017 by Rod Smith
# Distributed under the terms of the GPLv3

if [ "$#" -ne 1 ] && [ "$#" -ne 0 ]; then
    echo "Usage: $0 [ {kernel-version} ]"
    exit 1
fi

if [ "$#" == 0 ]; then
    kernel_version=$(uname -r)
else
    kernel_version="$1"
fi

sign_file=$(find /usr/src/ -name sign-file | tail -n 1)

if [ -z $sign_file ]; then
    echo "Can't find the sign-file binary! Exiting!"
    exit 1
else
    path_to_modules="/lib/modules/$kernel_version/updates/dkms"

    if [ ! -f $path_to_modules/vboxdrv.ko ]; then
        echo "Could not find $path_to_modules/vboxdrv.ko!"
        echo "Is the kernel version correct?"
        exit 1
    fi

    echo "Signing modules for $kernel_version"
    $sign_file sha256 /etc/refind.d/keys/refind_local.key /etc/refind.d/keys/refind_local.cer $path_to_modules/vboxdrv.ko
    $sign_file sha256 /etc/refind.d/keys/refind_local.key /etc/refind.d/keys/refind_local.cer $path_to_modules/vboxnetadp.ko
    $sign_file sha256 /etc/refind.d/keys/refind_local.key /etc/refind.d/keys/refind_local.cer $path_to_modules/vboxnetflt.ko
    $sign_file sha256 /etc/refind.d/keys/refind_local.key /etc/refind.d/keys/refind_local.cer $path_to_modules/vboxpci.ko
    modprobe vboxdrv
    modprobe vboxnetflt
    modprobe vboxpci
    modprobe vboxnetadp
    echo "Loaded vbox modules:"
    lsmod | grep vbox
fi

To use this script, simply type its name. It signs the VirtualBox modules associated with the currently-running kernel. If you pass it a kernel version number, it should sign the kernels associated with that kernel version, but there's no room for error in specifying the kernel version number. (It expects the same format that uname -r would return if the kernel were running.)

Note that the script expects to find private (refind_local.key) and public (refind_local.cer) keys in /etc/refind.d/keys/. You'll have to change that location for your own system, unless you use rEFInd and use local keys for it. The private key file should be as secure as you can make it, such as having 0400 (-r--------) permissions. Limiting access to the directory itself may be helpful, too. Better yet, put it on a USB flash drive that you plug in only when you run this command.

Also, I wrote this script for my own personal use. It probably has bugs, particularly if used in a way I don't expect. Certainly it fails pretty badly if the necessary kernel source files aren't installed.

It's conceivable that this script would work with the MOK-based methods you tried to use if you pointed it at the key files you generated, the public file of which you loaded into the MOK. I can't promise this, though, and of course your problems could be due to either improperly signed kernel modules or problems on the Shim/MOK end. Using this script would help only if your kernel modules were not properly signed.

Solution 2

VirtualBox 6.1 will install on 19.10 with secure boot enabled.

Comments

[Raphael]

FWIW, for googlers: with Ubuntu 18.04, installing aptitude install virtualbox virtualbox-dkms will sign the module and ask you for a one-time (?) password. Reboot, enter MOK config and enroll the key using that password.

[excalibur1491]

Thanks a lot! Reading your answer I realized I skipped a step in the other post I linked to. I did not need to do your step one, but I kept your very handy script ;). Also, for future readers, I then had a problem when trying to run a VM because the VM acceleration was disabled. For reference: askubuntu.com/questions/256792/…

[Rod Smith]

Skipping a step will often cause problems! ;) A script helps make that less likely.

[Chaim Eliyah]

But not on 21.04.

[user1325696]

Why virtualbox is doing this? I have installed KVM and I was not asked for anything similar. Why VirtualBox needs that?

[Rod Smith]

VirtualBox relies on out-of-tree kernel drivers. Such drivers must be signed if Secure Boot is in use; that's simply the design of Secure Boot (and the way the Linux kernel tries to keep itself secure). I'm less familiar with KVM, but it's presumably not using any out-of-tree kernel drivers.

[Admin]

And not on 22.04.