From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 30 13:26:04 2021 Received: (at 52882) by debbugs.gnu.org; 30 Dec 2021 18:26:04 +0000 Received: from localhost ([127.0.0.1]:54444 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n307o-00063x-45 for submit@debbugs.gnu.org; Thu, 30 Dec 2021 13:26:04 -0500 Received: from [129.159.192.69] (port=41776 helo=mail.pavluk.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n307l-00063S-Gq for 52882@debbugs.gnu.org; Thu, 30 Dec 2021 13:26:03 -0500 Received: from [192.168.1.59] (unknown [185.65.135.240]) by mail.pavluk.org (Postfix) with ESMTPSA id 09A8C8019973; Thu, 30 Dec 2021 18:25:54 +0000 (UTC) Message-ID: <0fcf6e432f009e05cb69143bee6009a92a13cad4.camel@pavluk.org> Subject: Re: [bug#52882] [PATCH] gnu: system: Add crypt-key field for mapped filesystems From: chayleaf To: Josselin Poiret , 52882@debbugs.gnu.org Date: Fri, 31 Dec 2021 01:25:44 +0700 In-Reply-To: <87ilv6fjhs.fsf@jpoiret.xyz> References: <20211229215713.1671606-1-chayleaf@pavluk.org> <87ilv6fjhs.fsf@jpoiret.xyz> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.2 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 4.8 (++++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > 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 [...] Content analysis details: (4.8 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.6 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL [129.159.192.69 listed in zen.spamhaus.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS X-Debbugs-Envelope-To: 52882 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 3.8 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > 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 [...] Content analysis details: (3.8 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.6 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL [129.159.192.69 listed in zen.spamhaus.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager > 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