elitak / nixos-infect

[GPLv3+] install nixos over the existing OS in a DigitalOcean droplet (and others with minor modifications)

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

wishlist: disk encryption

risicle opened this issue · comments

It would be nice to be able to set up a machine with disk encryption using nixos-infect - particularly in situations where you don't have 100% assurance of the provider's disk-wiping procedure between tenants.

There are obviously a lot of challenges with this. LUKS-based full disk encryption is probably completely out of the question because of the way we start with an existing root filesystem. However I could imagine some mechanism using linux's "fscrypt" native filesystem encryption being possible. For instance it would be quite possible to set an encryption key for the empty /nix directory as it is created. It would be a little trickier for /home and /var but perhaps not impossible.

There would still be a lot of questions about how to provide the key to the instance at boot - NixOS's fscrypt support appears to be pretty basic and existing mechanisms seem to be centered around using pam to provide a user's key at login-time for homedir decryption.

Arguably there may even be some value in encryption when the key is stored on the disk - as long as you have the ability to ensure that region is overwritten before relinquishing the instance.

Did a bit more investigation, and most paths forward seem tricky.

It looks to me like achieving this would need modifications to the upstream lustrate code in stage 1, which probably rules out the hackiest (easiest?) of solutions as there would (quite rightly) be a higher standard expected for acceptance.

One of the awkward aspects comes from how the lustrate process will purge the root fs directory of everything but /nix and /boot, which would cause other dirs to be initialized from-scratch, losing any encryption context given to them by nixos-infect. A possibility would be to introduce a piece of configuration akin to NIXOS_LUSTRATE that listed a set of top-level directories that the boot process should ensure exist and are set to the lustrate-crypt's encryption context.

This would be lacking the elegance of NIXOS_LUSTRATE - which is not needed after the first boot - whereas this would need to be performed on every boot. This is one of those places where nixos' attitude to (parts of) the root filesystem being fairly ephemeral works against us.

Perhaps framing it as a lustrate-related feature at all is unhelpful and perhaps it could be called toplevelFSCrypt, earlyFSCrypt, betterThanNothingFSCrypt.