nix-community / lanzaboote

Secure Boot for NixOS [maintainers=@blitz @raitobezarius @nikstur]
GNU General Public License v3.0
925 stars 44 forks source link

Sign kernel modules and enable kernel lockdown #88

Open Tom-Hubrecht opened 1 year ago

Tom-Hubrecht commented 1 year ago

Once secureboot is enabled, it is possible to lock down the kernel, although module signing is disabled by default ( https://github.com/NixOS/nixpkgs/blob/nixos-22.11/pkgs/os-specific/linux/kernel/common-config.nix#L514-L517 ). Furthermore, it is possible to feed a custom key for signing the kernel and its modules ( https://www.kernel.org/doc/html/v4.15/admin-guide/module-signing.html ), which we could use the secureboot keys for. It would also allow for the signature of other kernel modules (e.g. virtualbox's kernel modules).

RaitoBezarius commented 1 year ago

If we can separate module signing in to a separate derivation, we could probably implement a signing derivation and a verification derivation here.

blitz commented 1 year ago

Wouldn't signing the modules as part of a derivation leave the signing key exposed in the Nix store? Ideally we would find a way to sign the kernel modules on nixos-rebuild.

baloo commented 1 year ago

This could be signed outside the nix-store and nix-store --imported into it.

RaitoBezarius commented 1 year ago

My remark was thinking also about the case where NixOS starts shipping kernel binaries with signed modules. I think it would be good to enable verification of those when substituting them.

We can leak the signing key through an ugly builtins.getEnv and impure env vars, protected behind a requiredFeatures to enable specific machines to perform the signature with the help of a local TPM or whatever.

I think your idea @baloo is not mutually exclusive, we can requireFile, but we need to know hashes (in advance, right?) because this is a FOD then.

RaitoBezarius commented 1 year ago

Debian does it this way: https://salsa.debian.org/ftp-team/code-signing/-/blob/master/secure-boot-code-sign.py#L163-L201

blitz commented 1 year ago

Debian does it this way: https://salsa.debian.org/ftp-team/code-signing/-/blob/master/secure-boot-code-sign.py#L163-L201

From the code it almost looks like they support detached signatures. That would be neat, because we could sign everything at nixos-rebuild time. But the docs imply that the signatures are embedded.

The other :hankey: is that the public key that Linux trusts needs to be baked into the kernel at build time. It would be really neat to hand this over from the boot loader.

CajuM commented 1 year ago

If we can separate module signing in to a separate derivation, we could probably implement a signing derivation and a verification derivation here.

Could we generate detached module signatures using kmodsign outside the store, import them into the store and concatenate them with existing modules? kmodsign.1

CajuM commented 1 year ago

Debian does it this way: https://salsa.debian.org/ftp-team/code-signing/-/blob/master/secure-boot-code-sign.py#L163-L201

From the code it almost looks like they support detached signatures. That would be neat, because we could sign everything at nixos-rebuild time. But the docs imply that the signatures are embedded.

The other 💩 is that the public key that Linux trusts needs to be baked into the kernel at build time. It would be really neat to hand this over from the boot loader.

Can't we use a machine owner key to sign the modules locally?

blitz commented 1 year ago

Mmh. Ideally, I would like to have detached signatures and we don't have to reimport anything into the nix store. But I'm not sure this is feasible. In any case, I currently don't really have time to play around with this. But if someone else is willing to produce a PoC of signed kernel modules and kernel lockdown that would really help things along here.