From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id MIqSMIIS6l+yTAAA0tVLHw (envelope-from ) for ; Mon, 28 Dec 2020 17:14:42 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id KMN+LIIS6l/lZwAAbx9fmQ (envelope-from ) for ; Mon, 28 Dec 2020 17:14:42 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 2750B9404D3 for ; Mon, 28 Dec 2020 17:14:42 +0000 (UTC) Received: from localhost ([::1]:43686 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ktw6T-0001xR-1e for larch@yhetil.org; Mon, 28 Dec 2020 12:14:41 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:46752) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ktw5q-0001Qh-De for bug-guix@gnu.org; Mon, 28 Dec 2020 12:14:02 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:53389) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ktw5q-0006rs-3d for bug-guix@gnu.org; Mon, 28 Dec 2020 12:14:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ktw5p-0004yr-Ug for bug-guix@gnu.org; Mon, 28 Dec 2020 12:14:01 -0500 X-Loop: help-debbugs@gnu.org Subject: bug#45512: Feature Request: keyfile support for LUKS volume opening Resent-From: raid5atemyhomework Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Mon, 28 Dec 2020 17:14:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 45512 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: 45512@debbugs.gnu.org X-Debbugs-Original-To: "bug-guix@gnu.org" Received: via spool by submit@debbugs.gnu.org id=B.160917559119076 (code B ref -1); Mon, 28 Dec 2020 17:14:01 +0000 Received: (at submit) by debbugs.gnu.org; 28 Dec 2020 17:13:11 +0000 Received: from localhost ([127.0.0.1]:36702 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ktw50-0004xb-W9 for submit@debbugs.gnu.org; Mon, 28 Dec 2020 12:13:11 -0500 Received: from lists.gnu.org ([209.51.188.17]:35760) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ktw4y-0004xS-Vv for submit@debbugs.gnu.org; Mon, 28 Dec 2020 12:13:10 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:46610) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ktw4y-0000zc-R6 for bug-guix@gnu.org; Mon, 28 Dec 2020 12:13:08 -0500 Received: from mail4.protonmail.ch ([185.70.40.27]:31693) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ktw4v-0006nf-UR for bug-guix@gnu.org; Mon, 28 Dec 2020 12:13:08 -0500 Date: Mon, 28 Dec 2020 17:12:59 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1609175582; bh=gxqSGWH7t7CyjIMn51dJA2WwGY44HwnLckTG+CaaxOo=; h=Date:To:From:Reply-To:Subject:From; b=cgO4yEbXCJdNvgCy/12u7pFvyPNdHuSH9YtAB2si39zQrpktMblEtOGiPY+IyW/Ji PBzINaDoF4ypWS0+emjSFfI9NKDKvpUTt2HpJMzNTUyQK/mKa5032M4mprwsAVYgyh gUKUMvqVx9IBzG7uHFb2z0HtPDkKRVZZnHas7+zQ= Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.70.40.27; envelope-from=raid5atemyhomework@protonmail.com; helo=mail4.protonmail.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: "bug-Guix" Reply-to: raid5atemyhomework , raid5atemyhomework From: raid5atemyhomework via Bug reports for GNU Guix X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -2.82 Authentication-Results: aspmx1.migadu.com; dkim=fail (headers rsa verify failed) header.d=protonmail.com header.s=protonmail header.b=cgO4yEbX; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of bug-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=bug-guix-bounces@gnu.org X-Migadu-Queue-Id: 2750B9404D3 X-Spam-Score: -2.82 X-Migadu-Scanner: scn1.migadu.com X-TUID: 703aedeOzRs2 Consider the following use-case: * I have a boot device including a partition backing `/`. * My `/home` is on a separate RAID array, because my homework is important = and I would like to not lose it. * Each disk in the RAID array is *separately* LUKS-encrypted. * This allows me to decommission any disk in the array by destroying its = LUKS header with `cryptsetup erase` on the decommissioned disk. * While I could instead encrypt the RAID block device, if I decommission = one of the members of the array, it might contain the LUKS header for the e= ncrypted device, and I am not confident that my passphrase "RAID5 is not a = good dog" is not known by anyone else. I also cannot `cryptsetup erase` the RAID block device as that would de= stroy all the data in the entire array. * For example, my classmates want to copy my homework, so if for example = one of the disks starts having trouble and I decide to send it back to the = seller for a replacement, my classmates might intercept the disk in the hop= e of copying my homework. Unfortunately, if I have several disks in my RAID array, then boot would be= painful as I would need to enter my passphrase for each disk in the array. In this case, I would appreciate instead using a keyfile. * I *also* encrypt my `/` root partition. * I use my passphrase "RAID5 is not a good dog" for this partition. * In the `/root` directory, I generate a keyfile by `dd if=3D/dev/random bs= =3D32 of=3D/root/keyfile`. * I individually LUKS-encrypt each disk in the array using the keyfile `/ro= ot/keyfile`. Then, on boot: * I `cryptsetup` my `/` root partition and enter my passphrase. * I mount `/`. * Each of my RAID disks is then opened by `cryptsetup` but specifying a `--= key-file` as `/root/keyfile`. * I assemble my array and open the LVM container on top and mount my `/home= `. This means that at boot, I just input a passphrase once, and this decrypts = a keyfile that can be used to open all the other LUKS devies on my system. This is a important use-case: * If I LUKS-encrypted my `/home` only, I run the risk that the LUKS header = is on a disk that I am decommissioning. Then, a classmate with possession of my passphrase "RAID5 is not a good d= og" and who intercepts the decommissioned disk may be able to recover part = of my precious homework and submit it to my professor and get good grades. * If instead I have a keyfile on my encrypted partition, my classmate not o= nly needs to know my passphrase "RAID5 is not a good dog" and have intercep= ted the decommissioned disk, they *also* have to gain access to my boot dis= k, which is safely inside my computer tower. * Because the keyfile is stored only on the `/root` directory, I can easily= destroy all my data (in case my classmates try to get at my actual compute= r tower) by doing a `cryptsetup erase` on the root partition. It also allows other use-cases: * If I am using HDDs in the RAID array, I might get tired of the low speed,= so I might decide to use a `bcache` or `dm-cache` with an SSD cache to spe= ed up my array. * The cache SSD must also be encrypted, otherwise if I decommission my SS= D cache device then it might contain my precious homework in unencrypted fo= rm. With a keyfile stored on an encrypted root partition, I can encrypt my = SSD cache without adding yet another passphrase to enter during boot. It seems to me that this model where the only device with a LUKS keyslot co= ntaining a pasphrase would be the root partition, and all other encrypted d= evices use a keyfile on the root partition, is generally a good basis for e= nsuring that my data is difficult for somebody else to access even as I upg= rade my system. There is of course the risk that the device with the root partition fails a= nd thus accidentally destroy all my data, thus reducing my reliability, but= I could `xxd /root/keyfile`, write down the hexdump on a piece of paper, t= hen store that piece of paper in the same facility where I store all my gol= d bullion. Similarly I could instead use a keyfile generated from a dozen words from `= /etc/dictionaries-common/words`, which would be easier to store on paper. To implement this, there is some overlap with https://issues.guix.gnu.org/4= 5497 Basically, we need as well an `arguments` field in `mapped-device` records,= where we can add `#:key-file` for LUKS mapped devices. Another is that we also need to have `dependencies` for `mapped-device`s, n= ot just for `file-system`s. Crucially, a `mapped-device` might depend on a `file-system` --- in this ca= se, a LUKS-encrypted container that uses a keyfile must wait for the filesy= stem that contains the keyfile to get mounted. In particular, I notice that existing `mapped-device-kind`s have ad hoc "wa= it for sources to come online" waitloops, when we should instead be using p= roper Shepherd `requirement` specifications. A complication here is that I am uncertain how Guix handles the root filesy= stem from the `initrd`.