Sign kernel modules and enable kernel lockdown

Tom-Hubrecht commented

2023-01-31 23:56:53 +00:00

(Migrated from github.com)

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).

👍 7

RaitoBezarius commented

2023-02-01 02:25:15 +00:00

(Migrated from github.com)

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

2023-02-02 15:35:25 +00:00

(Migrated from github.com)

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.

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

2023-02-02 17:08:57 +00:00

(Migrated from github.com)

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

This could be signed outside the `nix-store` and `nix-store --import`ed into it.

RaitoBezarius commented

2023-02-02 17:23:45 +00:00

(Migrated from github.com)

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.

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

2023-03-28 18:22:38 +00:00

(Migrated from github.com)

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

blitz commented

2023-04-04 08:21:02 +00:00

(Migrated from github.com)

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.

> 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](https://www.kernel.org/doc/html/v4.15/admin-guide/module-signing.html) 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.

👍 2

CajuM commented

2023-11-12 18:18:54 +00:00

(Migrated from github.com)

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

> 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](https://manpages.ubuntu.com/manpages/impish/man1/kmodsign.1.html)

CajuM commented

2023-11-12 18:20:25 +00:00

(Migrated from github.com)

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?

> > 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](https://www.kernel.org/doc/html/v4.15/admin-guide/module-signing.html) 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

2023-11-12 18:48:13 +00:00

(Migrated from github.com)

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.

leo60228 commented

2024-12-02 23:23:20 +00:00

(Migrated from github.com)

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.

I think secure boot keys are also trusted. See the logic in https://github.com/torvalds/linux/blob/master/security/integrity/platform_certs/load_uefi.c.

Signatures are simply concatenated to the .ko file. It might be possible to patch kmod to support detached signatures.

> 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. I think secure boot keys are also trusted. See the logic in https://github.com/torvalds/linux/blob/master/security/integrity/platform_certs/load_uefi.c. Signatures are simply concatenated to the .ko file. It might be possible to patch `kmod` to support detached signatures.

RaitoBezarius commented

2024-12-02 23:27:14 +00:00

(Migrated from github.com)

Oh great, then, we are reduced to solve the problem of passing the Secure Boot signer in the Nix derivation for the kernel for those who really want to use signed kernel modules. That's nice!

baloo commented

2024-12-02 23:44:09 +00:00

(Migrated from github.com)

debian had a patch on modprobe (I think that was modprobe, could be another one) for a while to support detached signature.

RaitoBezarius commented

2025-01-25 19:29:13 +00:00

(Migrated from github.com)

A solution we will be able to make use of is sitting in a patch series in the kernel MLs: https://lore.kernel.org/all/20250120-module-hashes-v2-0-ba1184e27b7f@weissschuh.net/.

leo60228 commented

2025-01-25 19:55:35 +00:00

(Migrated from github.com)

Does that solution allow adding additional hashes at signing time for out-of-tree modules?

CajuM commented

2025-01-25 20:34:52 +00:00

(Migrated from github.com)

Does that solution allow adding additional hashes at signing time for out-of-tree modules?

In principle it's just an array of module hashes, anything can go into it. However, the current patch-series embeds only the hashes of modules built as part of the Linux kernel into that array...

> Does that solution allow adding additional hashes at signing time for out-of-tree modules? In principle it's just an array of module hashes, anything can go into it. However, the current patch-series embeds only the hashes of modules built as part of the Linux kernel into that array...

thillux commented

2025-07-02 15:08:37 +00:00

(Migrated from github.com)

I also played with externallay signed modules in order to enable lockdown and fips mode together with out-of-tree modules. Feel free to comment on my rough sketch in https://github.com/NixOS/nixpkgs/pull/401493. This can't be enabled by default due to reproducibility issues but is nevertheless sometimes useful IMHO.

Rows
Columns

Sign kernel modules and enable kernel lockdown #88