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

Previous Next

Package: guix-patches;

Reported by: chayleaf <chayleaf <at> pavluk.org>

Date: Wed, 29 Dec 2021 22:15:01 UTC

Severity: normal

Tags: patch

Full log


View this message in rfc822 format

From: chayleaf <chayleaf <at> pavluk.org>
To: Josselin Poiret <dev <at> jpoiret.xyz>, 52882 <at> debbugs.gnu.org
Subject: [bug#52882] [PATCH] gnu: system: Add crypt-key field for mapped filesystems
Date: Fri, 31 Dec 2021 01:25:44 +0700
> 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




This bug report was last modified 3 years and 159 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.