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

[Josselin Poiret]

Hello,

chayleaf <chayleaf@pavluk.org> writes:

> 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?

It would indeed be fine.  The open-luks-device g-exp is executed at
boot, in early userspace (ie no root mounted yet, still in the
initramfs), by `build-system` in (gnu build linux-boot) as a member of
`pre-mount`.

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

Yes, this is what I was suggesting, although I don't really know how
Linux handles multiple initrds.  Is the resulting initramfs a union of
the different initrds?

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

Agreed.

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

Out-of-store that's specified by the user seems like a good idea.  Do
you think you could handle adding additional initrd support to GRUB?  I
don't think it should be that hard.

Apart from that, the patch would be ok to merge for me if there was some
accompanying documentation that describes the security risks in a way
that would be understable for a layperson.

Best,
Josselin Poiret