nixos/stage1: copy initrd secrets into place after special mounts

[ddz]

Motivation for this change

This modifies initialRamdiskSecretAppender to stage secrets in /initrd-secrets/ and stage-1-init to copy them into place after mounting special file systems. This allows secrets to be copied into ramfs mounts like /run/keys for use after stage-1 finishes without copying them to disk (which would not be very secure). This is useful for ZFS filesystem key files, which are mounted later, as well as when rebuilding system configurations to be able to pull secret from /run/keys to rebuild the initrd.

Things done

Tested on release-21.05 branch and master to preserve existing functionality as well as enable a destinations for secrets in /run/keys which were present after system had booted.

Updated test in tests/initrd-secrets.nix to verify new behavior.

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• 21.11 Release Notes (or backporting 21.05 Relase notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

[ddz]

Thanks for the review! I responded to your suggestion re: find, fixed tabs, and squashed back into this PR.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-ready-for-review/3032/559

[ddz]

cc: @Mic92 - you reviewed one of my PRs a few years back, would you mind taking a look at this small one?

[dasJ]

How would that approach be secure in any way? Your initrd is usually unencrypted and so are the secrets inside. Since your secrets are already in your unencrypted initrd in your unencrypted /boot, why not store them in your regular filesystem as well?

[ddz]

How would that approach be secure in any way? Your initrd is usually unencrypted and so are the secrets inside. Since your secrets are already in your unencrypted initrd in your unencrypted /boot, why not store them in your regular filesystem as well?

@dasJ: Thank you for the review! This PR doesn't change how secrets are stored or where. It is only modifying them in a way to permit the system configuration to keep a copy on one of the special file systems after the initrd is done (to have, for example a clean contract between initrd and runtime where needed secrets are available in /run). In the case of my systems, I have a LUKS-encrypted /boot, which keeps the secrets initrd encrypted when powered off and I'm (slowly, sporadically) working on something which keeps them encrypted (e.g. TPM sealed) on the /boot filesystem as well.

[dasJ]

Suggested change

	for secret in $(cd "/.initrd-secrets"; find . -type f); do
	for secret in $(find /.initrd-secrets -not -type d); do

[ddz]

Hello! @SuperSandro2000 suggested the same thing here, but that changes the output and paths assigned to secret (they would have /.initrd-secrets/ still prepended vs. being the full path specified as the attribute name to boot.initrd.secrets). I chose this approach rather than having to strip the first path component inside the loop, which would be less precise. In addition, -not -type d is not equivalent to explicitly including files (-type f), it could include links, sockets, device nodes, etc.

I tried to explain the above in the comment preceding the loop, but if it's still not clear to reviewers, I should try to clarify more.

[dasJ]

I still don't see any point in having "secrets" that are in the plain initrd but there's really also no reason we shouldn't allow for this if this is functionality people want to have

[ddz]

Thank you for the merge!