[bug#52882] [PATCH] gnu: system: Add crypt-key field for mapped filesystems

[chayleaf]

> The open-luks-device gexp, along with the whole passphrase [1], end
> up in the boot script in the store, and the guix store is r-xr-xr-x,
> meaning that any program on your computer is able to read it.

Wouldn't it be fine if the key is stored on an external device and the
user supplies a G-Expression that loads it?  Or is the G-Expression
executed at reconfigure as opposed to at boot?

Storing the key itself is indeed insecure.  However, I think the
ability to load the key from something other than user input could
become a building block for hardcoding the key in more secure ways. 
For example, as far as I can tell, Grub supports multiple initrd
images [1], if the user puts their key on the boot partition in the
cpio format and tells Grub to use it as a secondary initrd, perhaps it
could be done.

I do agree that at the very least the potential security issues
hardcoding the key can cause need to be documented.


> On other distros, you can simply have keyfiles and initrds root-owned
> and r--------, and I think you could do something similar here, but
> you'd have to keep them out of the store and load them separately. 
> This
> could be a solution, but I don't know off the top of my head how one
> could implement it.

The biggest problem is there need to be multiple generations available
at the same time.  While you could create a separate "private" only-
read-by-root initrd store for this purpose, that would be too much work
for just a single feature.  A possible compromise is maintaining a
single out-of-store initrd at a given time, or, combined with the
above, the "secret" initrd parts could be stored in a separate archive,
similar to how grub resides in its own directory outside of the store.

[1] https://www.gnu.org/software/grub/manual/grub/html_node/initrd.html