From unknown Fri Jun 13 11:38:17 2025 X-Loop: help-debbugs@gnu.org Subject: [bug#52882] [PATCH] gnu: system: Add crypt-key field for mapped filesystems Resent-From: chayleaf Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Wed, 29 Dec 2021 22:15:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 52882 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: 52882@debbugs.gnu.org Cc: chayleaf , chayleaf X-Debbugs-Original-To: guix-patches@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.164081606325668 (code B ref -1); Wed, 29 Dec 2021 22:15:01 +0000 Received: (at submit) by debbugs.gnu.org; 29 Dec 2021 22:14:23 +0000 Received: from localhost ([127.0.0.1]:50564 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n2hDC-0006fv-Nz for submit@debbugs.gnu.org; Wed, 29 Dec 2021 17:14:23 -0500 Received: from lists.gnu.org ([209.51.188.17]:56912) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n2gwk-00069L-Nx for submit@debbugs.gnu.org; Wed, 29 Dec 2021 16:57:23 -0500 Received: from eggs.gnu.org ([209.51.188.92]:52608) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n2gwk-0001Bv-EB for guix-patches@gnu.org; Wed, 29 Dec 2021 16:57:22 -0500 Received: from [129.159.192.69] (port=40830 helo=mail.pavluk.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n2gwi-0006hg-BB for guix-patches@gnu.org; Wed, 29 Dec 2021 16:57:22 -0500 Received: by mail.pavluk.org (Postfix, from userid 1006) id 723AE801914A; Wed, 29 Dec 2021 21:57:17 +0000 (GMT) From: chayleaf Date: Wed, 29 Dec 2021 21:57:13 +0000 Message-Id: <20211229215713.1671606-1-chayleaf@pavluk.org> X-Mailer: git-send-email 2.27.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Host-Lookup-Failed: Reverse DNS lookup failed for 129.159.192.69 (failed) Received-SPF: pass client-ip=129.159.192.69; envelope-from=chayleaf@pavluk.org; helo=mail.pavluk.org X-Spam_score_int: 41 X-Spam_score: 4.1 X-Spam_bar: ++++ X-Spam_report: (4.1 / 5.0 requ) RCVD_IN_PBL=3.335, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Mailman-Approved-At: Wed, 29 Dec 2021 17:14:21 -0500 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: -2.3 (--) From: chayleaf This is a patch that adds a new field for mapped-filesystem that allows one to specify the LUKS encryption key via G-Expressions. An example use case is using a key stored on an external device. Sorry if I made a mistake anywhere, I'm new to both Lisp and mailing lists. * gnu/system/mapped-devices.scm (mapped-device-kind): Add crypt-key field. (open-luks-device): Use crypt-key as the encryption key if it's provided. * gnu/system/linux-initrd.scm (raw-initrd)[device-mapping-commands]: Utilize the crypt-key field. * doc/guix.texi (Mapped Devices): Add crypt-key to mapped-device docs. Signed-off-by: chayleaf --- doc/guix.texi | 7 ++++ gnu/system/linux-initrd.scm | 11 ++--- gnu/system/mapped-devices.scm | 77 +++++++++++++++++++++++------------ 3 files changed, 63 insertions(+), 32 deletions(-) diff --git a/doc/guix.texi b/doc/guix.texi index ebfcfee7f7..22495b0cbd 100644 --- a/doc/guix.texi +++ b/doc/guix.texi @@ -15125,6 +15125,13 @@ there are several. The format is identical to @var{target}. @item type This must be a @code{mapped-device-kind} object, which specifies how @var{source} is mapped to @var{target}. + +@item crypt-key +A G-Expression (see @pxref{G-Expressions}) or a bytevector to be used as the +encryption key for this device. If none is specified, the user will be asked +to enter their passphrase. It can be used for fetching the key from an +external device or avoiding to enter the passhprase two times with encrypted +@code{/boot}. @end table @end deftp diff --git a/gnu/system/linux-initrd.scm b/gnu/system/linux-initrd.scm index c78dd09205..36700d91ae 100644 --- a/gnu/system/linux-initrd.scm +++ b/gnu/system/linux-initrd.scm @@ -203,11 +203,12 @@ (define* (raw-initrd file-systems (define device-mapping-commands ;; List of gexps to open the mapped devices. (map (lambda (md) - (let* ((source (mapped-device-source md)) - (targets (mapped-device-targets md)) - (type (mapped-device-type md)) - (open (mapped-device-kind-open type))) - (open source targets))) + (let* ((source (mapped-device-source md)) + (targets (mapped-device-targets md)) + (type (mapped-device-type md)) + (crypt-key (mapped-device-crypt-key md)) + (open (mapped-device-kind-open type))) + (open source targets #:crypt-key crypt-key))) mapped-devices)) (define file-system-scan-commands diff --git a/gnu/system/mapped-devices.scm b/gnu/system/mapped-devices.scm index 96a381d5fe..4f680b71fe 100644 --- a/gnu/system/mapped-devices.scm +++ b/gnu/system/mapped-devices.scm @@ -50,6 +50,7 @@ (define-module (gnu system mapped-devices) mapped-device-target mapped-device-targets mapped-device-type + mapped-device-crypt-key mapped-device-location mapped-device-kind @@ -80,6 +81,8 @@ (define-record-type* %mapped-device (source mapped-device-source) ;string | list of strings (targets mapped-device-targets) ;list of strings (type mapped-device-type) ; + (crypt-key mapped-device-crypt-key ;bytevector | gexp + (default (const #f))) (location mapped-device-location (default (current-source-location)) (innate))) @@ -107,7 +110,7 @@ (define-deprecated (mapped-device-target md) (define-record-type* mapped-device-kind make-mapped-device-kind mapped-device-kind? - (open mapped-device-kind-open) ;source target -> gexp + (open mapped-device-kind-open) ;source target #:key (crypt-key #f) -> gexp (close mapped-device-kind-close ;source target -> gexp (default (const #~(const #f)))) (check mapped-device-kind-check ;source -> Boolean @@ -188,7 +191,10 @@ (define missing ;;; Common device mappings. ;;; -(define (open-luks-device source targets) +(define* (open-luks-device source targets #:key + (crypt-key #f) + #:allow-other-keys + #:rest rest) "Return a gexp that maps SOURCE to TARGET as a LUKS device, using 'cryptsetup'." (with-imported-modules (source-module-closure @@ -200,7 +206,9 @@ (define (open-luks-device source targets) (uuid-bytevector source) source))) ;; XXX: 'use-modules' should be at the top level. - (use-modules (rnrs bytevectors) ;bytevector? + (use-modules (ice-9 binary-ports) ;put-bytevector + (ice-9 popen) ;open-pipe* + (rnrs bytevectors) ;bytevector? ((gnu build file-systems) #:select (find-partition-by-luks-uuid)) ((guix build utils) #:select (mkdir-p))) @@ -211,28 +219,37 @@ (define (open-luks-device source targets) ;; Use 'cryptsetup-static', not 'cryptsetup', to avoid pulling the ;; whole world inside the initrd (for when we're in an initrd). - (zero? (system* #$(file-append cryptsetup-static "/sbin/cryptsetup") - "open" "--type" "luks" - - ;; Note: We cannot use the "UUID=source" syntax here - ;; because 'cryptsetup' implements it by searching the - ;; udev-populated /dev/disk/by-id directory but udev may - ;; be unavailable at the time we run this. - (if (bytevector? source) - (or (let loop ((tries-left 10)) - (and (positive? tries-left) - (or (find-partition-by-luks-uuid source) - ;; If the underlying partition is - ;; not found, try again after - ;; waiting a second, up to ten - ;; times. FIXME: This should be - ;; dealt with in a more robust way. - (begin (sleep 1) - (loop (- tries-left 1)))))) - (error "LUKS partition not found" source)) - source) - - #$target))))))) + (let ((crypt-key #$crypt-key) + (cryptsetup-cmdline (list #$(file-append cryptsetup-static "/sbin/cryptsetup") + "open" "--type" "luks" + + ;; Note: We cannot use the "UUID=source" syntax here + ;; because 'cryptsetup' implements it by searching the + ;; udev-populated /dev/disk/by-id directory but udev may + ;; be unavailable at the time we run this. + (if (bytevector? source) + (or (let loop ((tries-left 10)) + (and (positive? tries-left) + (or (find-partition-by-luks-uuid source) + ;; If the underlying partition is + ;; not found, try again after + ;; waiting a second, up to ten + ;; times. FIXME: This should be + ;; dealt with in a more robust way. + (begin (sleep 1) + (loop (- tries-left 1)))))) + (error "LUKS partition not found" source)) + source) + + #$target))) + (or (and (bytevector? crypt-key) + (let ((port (apply open-pipe* + (cons OPEN_WRITE + (append cryptsetup-cmdline + (list "--key-file" "-")))))) + (put-bytevector port crypt-key) + (zero? (status:exit-val (close-pipe port))))) + (zero? (apply system* cryptsetup-cmdline))))))))) (define (close-luks-device source targets) "Return a gexp that closes TARGET, a LUKS device." @@ -271,7 +288,10 @@ (define luks-device-mapping (close close-luks-device) (check check-luks-device))) -(define (open-raid-device sources targets) +(define* (open-raid-device sources targets #:key + (crypt-key #f) + #:allow-other-keys + #:rest rest) "Return a gexp that assembles SOURCES (a list of devices) to the RAID device TARGET (e.g., \"/dev/md0\"), using 'mdadm'." (match targets @@ -312,7 +332,10 @@ (define raid-device-mapping (open open-raid-device) (close close-raid-device))) -(define (open-lvm-device source targets) +(define* (open-lvm-device source targets #:key + (crypt-key #f) + #:allow-other-keys + #:rest rest) #~(and (zero? (system* #$(file-append lvm2-static "/sbin/lvm") "vgchange" "--activate" "ay" #$source)) -- 2.34.1 From unknown Fri Jun 13 11:38:17 2025 X-Loop: help-debbugs@gnu.org Subject: [bug#52882] [PATCH] gnu: system: Add crypt-key field for mapped filesystems Resent-From: Josselin Poiret Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Thu, 30 Dec 2021 10:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 52882 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: chayleaf , 52882@debbugs.gnu.org Cc: chayleaf , chayleaf Received: via spool by 52882-submit@debbugs.gnu.org id=B52882.16408618469260 (code B ref 52882); Thu, 30 Dec 2021 10:58:02 +0000 Received: (at 52882) by debbugs.gnu.org; 30 Dec 2021 10:57:26 +0000 Received: from localhost ([127.0.0.1]:51516 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n2t7d-0002PI-TB for submit@debbugs.gnu.org; Thu, 30 Dec 2021 05:57:26 -0500 Received: from jpoiret.xyz ([206.189.101.64]:43738) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n2t7b-0002P8-Dr for 52882@debbugs.gnu.org; Thu, 30 Dec 2021 05:57:24 -0500 Received: from authenticated-user (jpoiret.xyz [206.189.101.64]) by jpoiret.xyz (Postfix) with ESMTPA id B19F0184F5B; Thu, 30 Dec 2021 10:57:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jpoiret.xyz; s=dkim; t=1640861841; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=jl8xUa4+/VCO7FmgzRpZ6lun/ktVHskuDvwjfQM8ZaE=; b=RQgwasDGYdDrg66BIYKCi7xeQC+ULig9NilOUP208pM4fDp6n3BERc3cWuZBFT1FAOOQQW mFQNkX7jCXofFypxL3gajNje8K+XQ0KD9f6IsXOKe9BZ/7jQVkVf9yTPjpZIXs4JkYzfmQ 85foFHGheKrhdhRcwMecz3LDlMJVYz/wCzljJUFFSRuzDT1dekJ9lZ4VV79kN+83Jkyhxo 3LcNdVEdKYmUgsl7VlmYdrwILT+ZJu/kZer5n0IkFQgBzxg+6e/h+l1D8wyeahMZpe07zZ kIIeTjMPmMIe5QuiXNxefXa3binp2DvSvwMrURh/5K3+qVo0lEt9/maYdPwAAQ== From: Josselin Poiret In-Reply-To: <20211229215713.1671606-1-chayleaf@pavluk.org> References: <20211229215713.1671606-1-chayleaf@pavluk.org> Date: Thu, 30 Dec 2021 11:57:19 +0100 Message-ID: <87ilv6fjhs.fsf@jpoiret.xyz> MIME-Version: 1.0 Content-Type: text/plain X-Spamd-Bar: / Authentication-Results: jpoiret.xyz; auth=pass smtp.auth=jpoiret@jpoiret.xyz smtp.mailfrom=dev@jpoiret.xyz X-Spam-Score: 2.5 (++) 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: Hello, chayleaf writes: > From: chayleaf > > This is a patch that adds a new field for mapped-filesystem that allows > one to specify the LUKS encryption key via G-Expressions. > An example use case [...] Content analysis details: (2.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs [URI: jpoiret.xyz (xyz)] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 0.5 FROM_SUSPICIOUS_NTLD From abused NTLD 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: 2.5 (++) 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: Hello, chayleaf writes: > From: chayleaf > > This is a patch that adds a new field for mapped-filesystem that allows > one to specify the LUKS encryption key via G-Expressions. > An example use case [...] Content analysis details: (2.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs [URI: jpoiret.xyz (xyz)] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 0.5 FROM_SUSPICIOUS_NTLD From abused NTLD 1.0 BULK_RE_SUSP_NTLD Precedence bulk and RE: from a suspicious TLD -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager Hello, chayleaf writes: > From: chayleaf > > This is a patch that adds a new field for mapped-filesystem that allows > one to specify the LUKS encryption key via G-Expressions. > An example use case is using a key stored on an external device. This is a feature that many people have on their wishlist, and it looks like your code would do precisely that, however I have to admit that I am against adding this code into master for security reasons. 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. This is a pretty significant security risk that can reduce the benefits of full-disk encryption to nothing, so having it easily available to users would work against them. Feel free to use this patch on your local installation though, if you understand the security risks :) 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. [1] the actual encryption key is stored encrypted inside the LUKS header, which is unlocked with a passphrase, roughly. -- Josselin Poiret From unknown Fri Jun 13 11:38:17 2025 X-Loop: help-debbugs@gnu.org Subject: [bug#52882] [PATCH] gnu: system: Add crypt-key field for mapped filesystems Resent-From: chayleaf Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Thu, 30 Dec 2021 18:27:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 52882 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Josselin Poiret , 52882@debbugs.gnu.org Received: via spool by 52882-submit@debbugs.gnu.org id=B52882.164088876423313 (code B ref 52882); Thu, 30 Dec 2021 18:27:01 +0000 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> From: chayleaf 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-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 From unknown Fri Jun 13 11:38:17 2025 X-Loop: help-debbugs@gnu.org Subject: [bug#52882] [PATCH] gnu: system: Add crypt-key field for mapped filesystems Resent-From: Josselin Poiret Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Fri, 31 Dec 2021 17:59:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 52882 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: chayleaf , 52882@debbugs.gnu.org Received: via spool by 52882-submit@debbugs.gnu.org id=B52882.16409735173298 (code B ref 52882); Fri, 31 Dec 2021 17:59:01 +0000 Received: (at 52882) by debbugs.gnu.org; 31 Dec 2021 17:58:37 +0000 Received: from localhost ([127.0.0.1]:57414 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n3MAm-0000r8-Uq for submit@debbugs.gnu.org; Fri, 31 Dec 2021 12:58:37 -0500 Received: from jpoiret.xyz ([206.189.101.64]:43874) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n3MAk-0000r0-Mi for 52882@debbugs.gnu.org; Fri, 31 Dec 2021 12:58:35 -0500 Received: from authenticated-user (jpoiret.xyz [206.189.101.64]) by jpoiret.xyz (Postfix) with ESMTPA id ADDB3184F27; Fri, 31 Dec 2021 17:58:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jpoiret.xyz; s=dkim; t=1640973513; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=CjZPF+4nPveVA05Vqdajc0N0x1AeI/pXi2/PkjvWmpM=; b=M7uVqLUO9m73mZ6ZiC9RHizH4U7/w0X0sljmssxX4TW3j0WFPcvaGmDbeTgrz9etHqXft0 ROg8+bCPzaiSbx7RYmMHdRecexnbMr+l2It71jgE85hBpmyy/lHiHtczZIfP7M6UoLPHIe qspmTCTmnRQiv7ldmezDtBGPpyzM2b57jurm6Z8DD/kaXAqwR82KlGe/b5MNm7UPvg+l9t 9w6pCRoiYiKwAFuiT8OX5HMoHcV6z9x8QSGmkrFmSY+i6XfCuzO5BBERBAnARIWVR9a+r5 foAcTi4CPmZ+ml15sXFClVz8Fs2sVOA2HBaeV9pjQPOoXrNnNhQFpvOuRMs1nA== From: Josselin Poiret In-Reply-To: <0fcf6e432f009e05cb69143bee6009a92a13cad4.camel@pavluk.org> References: <20211229215713.1671606-1-chayleaf@pavluk.org> <87ilv6fjhs.fsf@jpoiret.xyz> <0fcf6e432f009e05cb69143bee6009a92a13cad4.camel@pavluk.org> Date: Fri, 31 Dec 2021 18:58:28 +0100 Message-ID: <87bl0wfygr.fsf@jpoiret.xyz> MIME-Version: 1.0 Content-Type: text/plain X-Spamd-Bar: / Authentication-Results: jpoiret.xyz; auth=pass smtp.auth=jpoiret@jpoiret.xyz smtp.mailfrom=dev@jpoiret.xyz X-Spam-Score: 2.5 (++) 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: Hello, chayleaf 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? Content analysis details: (2.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs [URI: jpoiret.xyz (xyz)] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 0.5 FROM_SUSPICIOUS_NTLD From abused NTLD 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: 2.5 (++) 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: Hello, chayleaf 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? Content analysis details: (2.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs [URI: jpoiret.xyz (xyz)] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 0.5 FROM_SUSPICIOUS_NTLD From abused NTLD 1.0 BULK_RE_SUSP_NTLD Precedence bulk and RE: from a suspicious TLD -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager Hello, chayleaf 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 From unknown Fri Jun 13 11:38:17 2025 X-Loop: help-debbugs@gnu.org Subject: [bug#52882] [PATCH] gnu: system: Add crypt-key field for mapped filesystems Resent-From: chayleaf Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Mon, 03 Jan 2022 19:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 52882 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Josselin Poiret , 52882@debbugs.gnu.org Received: via spool by 52882-submit@debbugs.gnu.org id=B52882.164123719219263 (code B ref 52882); Mon, 03 Jan 2022 19:14:02 +0000 Received: (at 52882) by debbugs.gnu.org; 3 Jan 2022 19:13:12 +0000 Received: from localhost ([127.0.0.1]:36228 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n4Slb-00050c-Ub for submit@debbugs.gnu.org; Mon, 03 Jan 2022 14:13:12 -0500 Received: from [129.159.192.69] (port=35054 helo=mail.pavluk.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n4SlW-000502-IC for 52882@debbugs.gnu.org; Mon, 03 Jan 2022 14:13:10 -0500 Received: from [192.168.225.66] (unknown [129.159.192.69]) by mail.pavluk.org (Postfix) with ESMTPSA id 22BDE801A3A6; Mon, 3 Jan 2022 19:12:59 +0000 (UTC) Message-ID: From: chayleaf Date: Tue, 04 Jan 2022 02:12:49 +0700 In-Reply-To: <87bl0wfygr.fsf@jpoiret.xyz> References: <20211229215713.1671606-1-chayleaf@pavluk.org> <87ilv6fjhs.fsf@jpoiret.xyz> <0fcf6e432f009e05cb69143bee6009a92a13cad4.camel@pavluk.org> <87bl0wfygr.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: 1.3 (+) 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: In advance, sorry if you received this message twice. The spam filters seemed to reject this E-mail at first. No idea if it will go through now, I'm still in the process of requesting a PTR entry. > 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? Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS 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: 0.3 (/) In advance, sorry if you received this message twice. The spam filters seemed to reject this E-mail at first. No idea if it will go through now, I'm still in the process of requesting a PTR entry. > 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? As far I know, the initrds are simply concatenated in-memory, and then the kernel extracts all of the images to a tmpfs. > Do you think you could handle adding additional initrd support to > GRUB? I don't think it should be that hard. I could totally do that, I would really appreciate it if you told me what the end-user interface should look like though. Currently, operating-system's initrd key is supposed to be a derivation, but in case of initrds that might contain the user's encryption key it should be a regular path. One option would be to change "initrd" to "initrds" (similar to mapped-device's "target" and "targets") and interpret string? initrds as a path. Another one is to add a new key in bootloader-configuration. A potential problem is that mounted paths and filesystem paths (I don't know the exact terminology) may differ - consider, for example, a separate /boot partition, or btrfs subvolumes. If mounted paths are used, it needs to be documented and the correct partition needs to be mounted in GRUB, if filesystem paths are used, it once again needs to be documented and the user needs to be able to specify not just the path, but also the device the initrd resides on. Also, I'm not sure all bootloaders support multiple initrds, and I can't test the EFI bootloaders. In particular, I couldn't find anything that could let one use multiple initrds in U-Boot documentation. You can load multiple images at different addresses, but I'm not sure whether that is enough to load multiple initrds. However, EXTLINUX documentation states "The initrd parameter supports multiple filenames separated by commas". From unknown Fri Jun 13 11:38:17 2025 X-Loop: help-debbugs@gnu.org Subject: [bug#52882] [PATCH] gnu: system: Add crypt-key field for mapped filesystems Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Wed, 05 Jan 2022 21:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 52882 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: chayleaf Cc: 52882@debbugs.gnu.org, Josselin Poiret , chayleaf Received: via spool by 52882-submit@debbugs.gnu.org id=B52882.164141764630198 (code B ref 52882); Wed, 05 Jan 2022 21:21:02 +0000 Received: (at 52882) by debbugs.gnu.org; 5 Jan 2022 21:20:46 +0000 Received: from localhost ([127.0.0.1]:39069 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n5DiA-0007r0-Ls for submit@debbugs.gnu.org; Wed, 05 Jan 2022 16:20:46 -0500 Received: from hera.aquilenet.fr ([185.233.100.1]:44620) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n5Di8-0007qk-U2 for 52882@debbugs.gnu.org; Wed, 05 Jan 2022 16:20:45 -0500 Received: from localhost (localhost [127.0.0.1]) by hera.aquilenet.fr (Postfix) with ESMTP id DE3911D7; Wed, 5 Jan 2022 22:20:38 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at aquilenet.fr Received: from hera.aquilenet.fr ([127.0.0.1]) by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlYkasQIVZit; Wed, 5 Jan 2022 22:20:38 +0100 (CET) Received: from ribbon (91-160-117-201.subs.proxad.net [91.160.117.201]) by hera.aquilenet.fr (Postfix) with ESMTPSA id D820A103; Wed, 5 Jan 2022 22:20:37 +0100 (CET) From: Ludovic =?UTF-8?Q?Court=C3=A8s?= References: <20211229215713.1671606-1-chayleaf@pavluk.org> Date: Wed, 05 Jan 2022 22:20:37 +0100 In-Reply-To: <20211229215713.1671606-1-chayleaf@pavluk.org> (chayleaf@pavluk.org's message of "Wed, 29 Dec 2021 21:57:13 +0000") Message-ID: <87o84pj2vu.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: / Authentication-Results: hera.aquilenet.fr; none X-Rspamd-Server: hera X-Rspamd-Queue-Id: DE3911D7 X-Spamd-Result: default: False [-0.10 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FREEMAIL_ENVRCPT(0.00)[protonmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FREEMAIL_CC(0.00)[debbugs.gnu.org,protonmail.com,jpoiret.xyz] X-Spam-Score: 1.0 (+) 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: -0.0 (/) Hello, One comment about the interface (the security showstopper Josselin described would need to be addressed first, though): chayleaf skribis: > --- a/gnu/system/mapped-devices.scm > +++ b/gnu/system/mapped-devices.scm > @@ -50,6 +50,7 @@ (define-module (gnu system mapped-devices) > mapped-device-target > mapped-device-targets > mapped-device-type > + mapped-device-crypt-key > mapped-device-location >=20=20 > mapped-device-kind > @@ -80,6 +81,8 @@ (define-record-type* %mapped-device > (source mapped-device-source) ;string | list of stri= ngs > (targets mapped-device-targets) ;list of strings > (type mapped-device-type) ; > + (crypt-key mapped-device-crypt-key ;bytevector | gexp > + (default (const #f))) > (location mapped-device-location > (default (current-source-location)) (innate))) The type is used for mapped devices other than LUKS, such as RAID devices. Thus, there=E2=80=99s no reason for there to be a =E2=80=98crypt-key=E2=80=99 field. Instead, the extra information should be passed in some other way, either via the =E2=80=98source=E2=80=99 field, or maybe via an extra =E2=80= =98arguments=E2=80=99 field that would be passed as-is to the mapped-device type handler. Thanks, Ludo=E2=80=99.