Signed Kernel

[FoolMonty]

Howdy,

Beginner's question, no doubt. I enabled Module signature verification, Require modules to be validly signed and Automatically sign all modules in the kernel and now programs with emerged modules wont work, notably virtualbox which is the first program I tried to run after the kernel change. I manually signed the modules ("vboxdrv" "vboxnetadp" and "vboxnetflt") as per the guide at http://wiki.gentoo.org/wiki/Signed_kernel_module_support and, after that failed, I also unmerged and re-emerged virtuabox and virtualbox-modules, but the program gives the same error

[N8Fear]

First: make sure that the modules are signed right now (e.g. via hexdump as in the link you posted).
If they are actually signed, try to load them (e.g. va modprobe) and look for errors (on the commandline and possibly in dmesg).
If there are errors: post them here would help us to diagnose the issue at hand.

[FoolMonty]

N8Fear, thank you for the reply and please accept my apology for not answering sooner

I cannot reproduce the error as I recompiled the kernel without the Require modules to be validly signed option to get a functional system back, but your answer seems to imply that the only option is to manually sign package installed modules. Is that correct?

I am not a developer and knowing the volunteer nature of this work, I wont dare ask that anything be changed but IMHO if package installed modules are not signed automatically when emerged then this security feature leaves a wide open hole for non expert users who do not know how to find all the modules installed by any given package or do not have the time to manually sign all the modules that might be installed with an emerge @world update (there are times that the number of packages can exceed 100).

As this post might be read by others who like myself would spend the time to seek the new modules and manually sign them if they only knew how to find them, any suggestion on a command that would help the user make a list of which modules were installed with an update?

Again, please accept my apology for not answering sooner. I am not an IT professional and I have a limited time to attend to these things.

[Hu]

Module signature checking is an upstream feature, whereas out-of-tree kernel modules installed by the package manager are dependent on the package manager, in this case Gentoo's Portage. It may be possible to arrange for the install process to automatically sign such modules, but I would be wary of doing so, since it then means that the signing key is not protected. As far as I know, even out-of-tree packages are installed to the kernel module directory, which is normally /lib/modules/$(uname -r). You can check for packages which install to this area to find modules which may require a signature. If you know when out-of-tree updates were last installed, you can use a find -newer predicate to search the module installation directory for modules new enough that they are likely from an unsigned out-of-tree install. The comments in init/Kconfig indicate that scripts/sign-file can perform the required signing for you.

[FoolMonty]

Hello Hu

[N8Fear]

If you secure the keys it's less likely that an attacker can use them (secure means a strong! passphrase). You even add a little bit security by obscurity (which is nice but definitely nothing to depend on), because an attacker needs to know about signed modules, how to create them, and find the keys.
On the other hand, if the system would be secure (which is impossible as everone hopefully knows) you wouldn't need to sign them in the first place.
Therefore you should assume that you have a skilled attacker that could be using a keylogger to get the passphrase.
Essentially it boils down to: if you want maximum security by using certificates or code signing is creating an airgap: a system just for codesigning that has no whatsoever connection to the host that should use the certified code. Ideally such a system has no connection to anything and is powered down unless you need to sign something.
This - depending on your goals and usecase - may be a little bit paranoid...

[Hu]

Keys left on the system are more vulnerable than those which are physically disconnected when not in use. Keys left on the system with no passphrase are more vulnerable than those left on the system with a passphrase. Most people who speak of signing in an automatic build assume that such signing happens with no human involvement at any phase, which can occur only when the keys are kept in a machine-readable (and attacker readable) form. If you required Portage to use a helper that prompted a human for the passphrase, the keys would be safer than if you did not do so. However, this would be inconvenient. Safety is relative and depends quite a bit on your threat model. If you assume that an adversary is only able to employ easy and well known public techniques, then such an adversary can be stopped by relatively light security. If you assume that the adversary will have an extended period alone with the system to explore and understand your defenses, then you need much stricter security.

For signing, use find /lib/modules/$(uname -r) -name '*.ko' -newer marker -print0 | while read -d '' ko; do sign_module "$ko"; done. I leave it to you to figure out the marker and construct an appropriate path and arguments to the signing script.

[salahx]

Normally. when kernel modules are signed, they are done so with a one-shot key - on each build, a key pair is generated, the private part used to sign the modules then tossed. The public key is then signed by a long-lived signing key.

There is a module_sign target (not listed in "make help") Makefile target for the linux kernel that signs all the modules after installation, thus one can do make module_install, then install any out of tree packages, then make module_sign to sign them all.

Signed modules are really more for binary distribution that need to shipped locked-down devices or deal with Secure Boot. Its far less useful under Gentoo. Even less so with out-of-tree modules - while they can be signed using the above technique is not being in done in practice. Especially not with something like the virtualbox kernel drivers - they may be GPL but they are abomination. The virtualbox kernel modules are essentially C++ code in a C wrapper.

[FoolMonty]

Hu, I have to thank you twice in one day

I will play with that (and will learn much in the process).

Best