kernel: enable module signing by eadwu · Pull Request #87426 · NixOS/nixpkgs

eadwu · 2020-05-09T20:26:11Z

This suffers from the same pitfalls as #86835, if the kernel needs to be rebuilt twice, the generated certificate will be wrong and thus the module is unable to be loaded due to the invalid certificate.

Though with the flawed approach to force the kernel to be the same, I included an example to show it works (zfs).

Motivation for this change

If lockdown is enabled, or module signatures are forced, unsigned modules are unable to be loaded.

Things done

eadwu · 2020-05-09T20:29:32Z

pkgs/top-level/all-packages.nix

Another shortcoming, due to differing hash algos, we need to specify a default or read it in from the output config.

ajs124 · 2020-05-15T02:17:21Z

pkgs/os-specific/linux/kernel/manual-config.nix

With the private signing key in the store, wouldn't this allow anyone on the system to sign arbitrary modules?

I thought it wouldn't be as much of a problem as the certs are generated on every kernel build since we don't supply one by default.

I also assumed that derivations in /nix/store wouldn't be writable by other things (if that's compromised I don't think anything I could do would be much better).

I'm not sure I understand? As long as the key is in the store, you can just take it and sign an arbitrary module with it, without ever needing to touch anything else in the nix store, right?

For my specific use case for this PR, it's to modprobe out of tree modules doing the boot phase. The only modules in the initrd are the result of a nix derivation so I'd expect that nothing would be compromised there.

I'm not sure if you can modprobe modules that aren't in the nix store, but if you can, then yeah, that would be a problem.

If it's just the act of signing arbitrary modules, then if the above isn't possible, then it shouldn't really matter, since if you can't use it, it doesn't make a difference?

I think you can load a module from anywhere if it's binary-compatible with your kernel.

Let's imagine the scenario: I somehow gained access to the insmod command (it loads a kernel module from a file and is a low-level interface to module loading facilities) and able to pass it any path (incorrect SUID configuration on a vulnerable program?). I could craft a kernel module for the same kernel you use (and I could make a reasonable guess by comparing the hashes, if you use a standard Nixpkgs kernel) and then inject it into the kernel.

If the private keys for signing kernel modules are in the /nix/store, I could try to exfiltrate them using the hashes to find the kernel directory (or just by using /run/booted-system?) and sign the module with them. Bam, I have kernel-level access.

One use-case I could imagine would be the builder nix store being kept secret (e.g. separate, access-restriced machine).

Without access to that, the security would hold on the target machine.

eadwu · 2020-05-15T03:09:12Z

Depends on #87856 for certain scenarios.

vikanezrimaya · 2020-11-11T11:20:47Z

Can one sign modules after-the-fact with a key and make the kernel recognize it without rebuilding? While I understand signing modules after building would hurt binary reproducibility of derivations including kernel modules (will it? I've heard signatures can be stripped easily if needed or even accidentally) it would allow the private keys to be outside of /nix/store.

This reverts commit 4938fc4.

Atemu · 2021-01-11T18:39:46Z

I also think signing modules and baking the key into the kernel after the fact would be the better approach.

It'd probably be best to do that outside a Nix drv honestly; a script that signs modules on nixos-rebuild switch could use any form of authentication you could want (e.g. private key inside a hardware token) and the kernel + modules need to be touched at that moment anyways.

eadwu · 2021-01-11T19:45:36Z

It is probably possible to inject the key afterwards, but I'm not sure how much effort it would require nor am I exactly really keen on doing so right now. This was just simple POC-ish thing that would allow booting (with external modules) to work with lockdown

If I recall correctly, the signature is just appended to the module (I think, I'm not sure, don't really remember), in which case yes, it will be easy to strip the signature afterwards.

Probably the way to go if we go this route is to let the kernel generate a key and sign its modules (with MODULE_SIG and whatnot config options), before stripping the signatures and public key in the fixupPhase, before doing some brittle monkey patching on the kernel (a good idea?) and resigning the modules, though it probably will result in an extra kernel and kernel-modules derivation in the store.

vikanezrimaya · 2021-03-05T01:23:16Z

I feel like whatever would be going on with keys and signing better happen out of my Nix store, preferably in the bootloader integration phase in the switching. It will make nixos-rebuild boot a little bit longer but a lot more secure.

I wish we could sign kernels for Secure Boot in a similar way... I've been thinking about doing it with a modified systemd-boot module, but my laptop turned out to have a glitchy UEFI and now I can't boot NixOS automatically, the UEFI entries just refuse to be modified.

stale · 2021-09-03T01:14:07Z

I marked this as stale due to inactivity. → More info

eadwu · 2021-09-03T01:26:43Z

Closing for now ... I'll see how this ends up going if I have time in between university and 2 research groups ...

eadwu commented May 9, 2020

View reviewed changes

eadwu force-pushed the kernel/sign-modules branch from c7ae5cf to 2bf1dc9 Compare May 15, 2020 02:14

ajs124 reviewed May 15, 2020

View reviewed changes

ofborg bot added the 8.has: package (new) This PR adds a new package label May 15, 2020

eadwu force-pushed the kernel/sign-modules branch from 2bf1dc9 to 67b1cdf Compare May 23, 2020 15:39

eadwu force-pushed the kernel/sign-modules branch from 67b1cdf to 8575b86 Compare June 30, 2020 19:48

ofborg bot requested review from layus, teto and thoughtpolice June 30, 2020 19:56

eadwu force-pushed the kernel/sign-modules branch 4 times, most recently from 47dfbfd to dafb287 Compare July 1, 2020 01:46

ofborg bot requested a review from abbradar July 1, 2020 01:54

eadwu force-pushed the kernel/sign-modules branch from dafb287 to 7ca0592 Compare July 1, 2020 22:13

eadwu force-pushed the kernel/sign-modules branch from 7ca0592 to 721f102 Compare July 20, 2020 02:17

eadwu force-pushed the kernel/sign-modules branch 3 times, most recently from 5283707 to 043b279 Compare August 16, 2020 18:42

ofborg bot added 6.topic: nixos Issues or PRs affecting NixOS modules, or package usability issues specific to NixOS 8.has: module (update) This PR changes an existing module in `nixos/` labels Aug 16, 2020

ofborg bot requested a review from Atemu August 16, 2020 19:29

ofborg bot removed 6.topic: nixos Issues or PRs affecting NixOS modules, or package usability issues specific to NixOS 8.has: module (update) This PR changes an existing module in `nixos/` labels Aug 16, 2020

eadwu force-pushed the kernel/sign-modules branch from 6b415af to 21e38db Compare August 17, 2020 01:47

eadwu force-pushed the kernel/sign-modules branch from 21e38db to 1fe16c6 Compare September 8, 2020 16:00

eadwu force-pushed the kernel/sign-modules branch from 1fe16c6 to 61f94cf Compare September 26, 2020 15:25

eadwu force-pushed the kernel/sign-modules branch from 61f94cf to afbaee8 Compare October 7, 2020 18:00

eadwu force-pushed the kernel/sign-modules branch from afbaee8 to 7305114 Compare October 29, 2020 20:15

eadwu force-pushed the kernel/sign-modules branch from 7305114 to 7aa45d1 Compare November 16, 2020 19:08

eadwu force-pushed the kernel/sign-modules branch from 7aa45d1 to bd5c201 Compare December 21, 2020 06:07

eadwu added 8 commits January 11, 2021 12:52

kernel: keep signing certificates

14b711c

kernel/autoModuleSignHook: init

ed6e166

zfs: sign module

5bda465

nvidia_x11: sign module

6067789

bbswitch: sign module

d4ed2f3

autoModuleSignHook: move to kernel.moduleBuildDependencies

b589a76

autoModuleSignHook: sign when aggregated

b82db97

Revert "autoModuleSignHook: sign when aggregated"

35f733f

This reverts commit 4938fc4.

eadwu force-pushed the kernel/sign-modules branch from bd5c201 to 35f733f Compare January 11, 2021 18:08

ofborg bot requested a review from andresilva January 11, 2021 19:42

SuperSandro2000 added the 2.status: merge conflict This PR has merge conflicts with the target branch label Jan 18, 2021

danielfullmer mentioned this pull request Jan 20, 2021

WIP: Sign systemd boot EFI images for secure booting. #53901

Closed

stale bot added the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Sep 3, 2021

stale bot removed the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Sep 3, 2021

eadwu closed this Sep 3, 2021

Uh oh!

Conversation

eadwu commented May 9, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Motivation for this change

Things done

Uh oh!

eadwu May 9, 2020

Choose a reason for hiding this comment

Uh oh!

ajs124 May 15, 2020

Choose a reason for hiding this comment

Uh oh!

eadwu May 15, 2020

Choose a reason for hiding this comment

Uh oh!

ajs124 May 15, 2020

Choose a reason for hiding this comment

Uh oh!

eadwu May 15, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vikanezrimaya Nov 11, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Atemu Jan 11, 2021

Choose a reason for hiding this comment

Uh oh!

eadwu commented May 15, 2020

Uh oh!

vikanezrimaya commented Nov 11, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Atemu commented Jan 11, 2021

Uh oh!

eadwu commented Jan 11, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vikanezrimaya commented Mar 5, 2021

Uh oh!

stale bot commented Sep 3, 2021

Uh oh!

eadwu commented Sep 3, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

eadwu commented May 9, 2020 •

edited

Loading

eadwu May 15, 2020 •

edited

Loading

vikanezrimaya Nov 11, 2020 •

edited

Loading

vikanezrimaya commented Nov 11, 2020 •

edited

Loading

eadwu commented Jan 11, 2021 •

edited

Loading