# Virtualbox modules fail to load without required keys

## paradigm-X

When I do 'modprobe vboxdrv' after emerging virtualbox, and rebooting, I get a message saying:

"modprobe: ERROR: could not insert 'vboxdrv': Required key not available"

Since I use the kernel feature requiring all modules to be signed (http://wiki.gentoo.org/wiki/Signed_kernel_module_support), I suppose this is an indication that it must be working. Anyway, I expected that these modules would have been signed before being released on Gentoo. I believe that I am now required to sign the virtualbox modules using the key generated when compiling the kernel? I have not seen this issue before. 

Instructions on that website explain the procedure for signing modules manually, and it looks straightforward. However, again, I would have expected these to be signed and before I put a blessing on them, I would like an opinion from someone in the know. 

Thanks.

----------

## Logicien

Hi,

I nerver use the signing of the Linux kernel modules, so my comment is about the fact that the VirtualBox modules are not part of the Linux kernel tree. According to what I read, signed modules are for the one in the kernel tree.

I haven't see any information that say you can sign modules out of the tree, in particular the ones who taint the kernel. I can be wrong because I am not sure of it.

According to what I read again, you may have to use the permissive signing (no signed and valid signed modules) to allow non signed modules to be load with valid signed ones. If you use the strict signing (only valid signed modules), you may be limited to the in kernel tree modules if you do not find a way to sign those out of the Linux kernel tree modules.

The Linux kernel help of signing modules talk about a file Documentation/module-signing.txt in the kernel root tree. I havent found it. A search on the Web display the contain of a file call module-signing.txt.

----------

## paradigm-X

Hello, Logicien. I found out that these modules can be signed by the kernel verification key in order to get them installed. I eventually just followed the instructions provided for using the script to sign them so that there was no need to decrease my hard enforcement options. I am glad the procedure and instructions were clear enough, but I was surprised to find that these modules were allowed to pass into the portage tree without having been signed already. Perhaps there was a licensing issue that caused it? Still, it sure seems as though a notice about it would have been provided in the build messages at the end of such procedures.

----------

## Aquous

 *paradigm-X wrote:*   

> Hello, Logicien. I found out that these modules can be signed by the kernel verification key in order to get them installed. I eventually just followed the instructions provided for using the script to sign them so that there was no need to decrease my hard enforcement options. I am glad the procedure and instructions were clear enough, but I was surprised to find that these modules were allowed to pass into the portage tree without having been signed already. Perhaps there was a licensing issue that caused it? Still, it sure seems as though a notice about it would have been provided in the build messages at the end of such procedures.

 What? Of course they wouldn't be signed - you built them yourself!

----------

## paradigm-X

Well, actually, I built the others too while compiling the kernel after picking which modules to make in menuconfig. Additionally, I use the same key for signing them all. Still, I get what you were trying to say. My point was that I was half expecting the manual signature, as opposed to the automatic signature, to be required only for kernel modules brought in from "external" sources, i.e., outside of the portage way.

----------

## Hu

How can Portage sign the module locally without knowing your key?  In addition to the new steps, you would also need a variable to point Portage to the signing key, and permissions lax enough that Portage could access it.

----------

## Logicien

The virtualbox-modules package have no USE flag related to sign it's modules and no USE flag too related to sign something for the other VirtualBox packages.

----------

## paradigm-X

 *Hu wrote:*   

> How can Portage sign the module locally without knowing your key?  In addition to the new steps, you would also need a variable to point Portage to the signing key, and permissions lax enough that Portage could access it.

 

You make a good point, Hu. I just made this kernel and these modules, and just started using this feature. So I may not have given adequate consideration to the entire process yet. This is a good occassion to do so. 

The method is described here: https://wiki.gentoo.org/wiki/Signed_kernel_module_support . It mentioned that there are two ways it can be utilized, one with automatic key generation and signing, and the other with manual key creation and signing. In either case, two keys are required, a public one and a private one. Similarly, when I make use of public key encryption for sending messages, there are also two keys utilized in the process of message generation and validation. I provide a public key to others so that, on the one hand, they can send me encrypted messages, which I then need the private key to decrypt, and so that, on the other hand, they can use the public key to validate the signature I place on message sent publically. 

Accordingly, I assumed a procedure like this would take place with these two keys created, either automatically or manually, and utilized by the kernel during compilation. The instructions from the above mentioned site, state the following in regard to the disposition of these two keys:

     "The resulting files need to be stored as signing_key.x509 and signing_key.priv in the root of the Linux kernel source tree.

     The public key part will be build inside the Linux kernel. If you configured the kernel to sign modules, this signing will take place during the make modules_install part."

Apparently, therefore, as the kernel was compiled, the public key portion would have been built into it by making use of either the automatically generated "public" key it created or the manually created "public" key put there, i.e., temporarily stored in '/usr/src/linux', by the user before the kernel was being compiled. It is this public key part of the set of keys that the kernel now uses to authenticate the modules that are loaded each time it boots or each time one of them get loaded with modprobe. Additionally, the signature on these modules, the one that it authenticates each time, would have to have been made with the private key part of this set. 

Now, since the private key is supposed to be removed from accessibility right after the kernel was built, it cannot be available to portage automatically in such a way that enable portage to sign any module later generated. Unless I am missing something, this is the process for the most part.

Finally, I would like to throw up one more idea for consideration although I have not entirely cogitated on its feasibility through and through. Would it not be swell if there were some way to further enhance this security by utilizing an authentication process not only with modules but also with programs themselves by somehow putting a signature onto the gcc program in order to make it sign the programs as it built them and later the kernel would authenticate them with its same corresponding public key, or possibly have it authenticate the gcc program itself anytime it were invoked to build a program?   :Smile: 

----------

## viralex

I expected portage to sign the modules.

As explained in gentoo's wiki (https://wiki.gentoo.org/wiki/Signed_kernel_module_support) I use this boring script to sign the modules.

```

#!/bin/bash

SIGN_SCRIPT="/usr/src/linux/scripts/sign-file"

KEY_PRIV="/usr/src/linux/signing_key.priv"

KEY_X509="/usr/src/linux/signing_key.x509"

MODULES_DIR="/lib64/modules/`uname -r`/misc"

perl $SIGN_SCRIPT sha512 $KEY_PRIV $KEY_X509 $MODULES_DIR/vboxdrv.ko

perl $SIGN_SCRIPT sha512 $KEY_PRIV $KEY_X509 $MODULES_DIR/vboxnetadp.ko

perl $SIGN_SCRIPT sha512 $KEY_PRIV $KEY_X509 $MODULES_DIR/vboxnetflt.ko

perl $SIGN_SCRIPT sha512 $KEY_PRIV $KEY_X509 $MODULES_DIR/vboxpci.ko

```

you can customize the script if you keep the keys somewere else  :Wink: 

----------

