Debian Bug report logs - #774647
can't a use key file stored on an encrypted rootfs to unlock the resume device at initramfs stage

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Łukasz Stelmach <stlman@poczta.fm>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: cryptsetup on initramfs does not support key files (resume swap on LVM)

Date: Mon, 05 Jan 2015 19:15:48 +0100

Package: cryptsetup
Version: 2:1.4.3-4
Severity: normal

Dear Maintainer,

I have the following setup (see below for the files)

+ /boot on /dev/sda1
+ root filesystem on /dev/mapper/sda2_cryptblk
+ /home, /var and swap on LVM on /dev/mapper/sdb2_crypt

--- blkid ---
/dev/mapper/vg1-home: LABEL="HOME" UUID="3c300542" TYPE="ext4" 
/dev/mapper/vg1-var:  LABEL="VAR"  UUID="c4be931f" TYPE="ext4" 
/dev/mapper/vg1-swap: LABEL="swap" UUID="cb8020c2" TYPE="swap" 
-------------

sda2_crypt is protected by a password I enter upon boot-up,
sdb2_crypt with a key file stored on the root filesystem.

I added resume=UUID=... pointing to my swap to the kernel command
line and ran update-initramfs and got the following message

cryptsetup: WARNING: target sdb2_crypt uses a key file, skipped

Apparently the cryptsetup initramfs scripts do not support my
case where a key file for a partition is stored on another
encrypted partition.

A simmilar use case has been described here:

https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/238163

-- Package-specific info:
-- /proc/cmdline
initrd=/initrd.img-3.2.0-4-amd64 root=/dev/mapper/sda2_crypt ro quiet resume=UUID=cb8020c2 BOOT_IMAGE=/vmlinuz-3.2.0-4-amd64 

-- /etc/crypttab
sda2_crypt UUID=2646df90 none luks
sdb2_crypt UUID=06e17a3e /root/sdb2.key luks

-- /etc/fstab
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/sda2_crypt        /               ext4    noatime,errors=remount-ro 0       1
# /boot was on /dev/sda1 during installation
UUID=abb3bb32 /boot           ext2    noatime,nodev,nosuid,noexec 0       2
UUID=c4be931f /var            ext4    defaults,noatime,errors=remount-ro 0 2
UUID=3c300542 /home           ext4    defaults,noatime,errors=remount-ro 0 2
UUID=cb8020c2 none            swap    defaults 0 0


-- lsmod
Module                  Size  Used by
parport_pc             22364  0 
ppdev                  12763  0 
lp                     17149  0 
parport                31858  3 lp,ppdev,parport_pc
rfcomm                 33700  0 
bnep                   17567  2 
bluetooth             119455  10 bnep,rfcomm
binfmt_misc            12957  1 
uinput                 17440  1 
nfsd                  216181  2 
nfs                   308353  0 
nfs_acl                12511  2 nfs,nfsd
auth_rpcgss            37143  2 nfs,nfsd
fscache                36739  1 nfs
lockd                  67306  2 nfs,nfsd
sunrpc                173730  6 lockd,auth_rpcgss,nfs_acl,nfs,nfsd
ext3                  162072  1 
jbd                    56902  1 ext3
ext2                   59231  1 
loop                   22641  0 
adt7475                21744  0 
hwmon_vid              12430  1 adt7475
snd_hda_codec_realtek   188851  1 
joydev                 17266  0 
arc4                   12458  2 
ath9k                  64619  0 
nouveau               583385  3 
ath9k_common           12728  1 ath9k
ath9k_hw              322112  2 ath9k_common,ath9k
snd_hda_intel          26259  2 
snd_hda_codec          78031  2 snd_hda_intel,snd_hda_codec_realtek
ath                    21370  3 ath9k_hw,ath9k_common,ath9k
video                  17683  1 nouveau
mac80211              192806  1 ath9k
snd_hwdep              13186  1 snd_hda_codec
ttm                    53664  1 nouveau
psmouse                69265  0 
snd_pcm                68083  2 snd_hda_codec,snd_hda_intel
drm_kms_helper         31370  1 nouveau
cfg80211              137243  3 mac80211,ath,ath9k
snd_page_alloc         13003  2 snd_pcm,snd_hda_intel
drm                   183952  5 drm_kms_helper,ttm,nouveau
snd_seq                45126  0 
rfkill                 19012  5 cfg80211,bluetooth
snd_seq_device         13176  1 snd_seq
snd_timer              22917  2 snd_seq,snd_pcm
mxm_wmi                12515  1 nouveau
evdev                  17562  12 
power_supply           13475  1 nouveau
i2c_algo_bit           12841  1 nouveau
snd                    52893  12 snd_timer,snd_seq_device,snd_seq,snd_pcm,snd_hwdep,snd_hda_codec,snd_hda_intel,snd_hda_codec_realtek
coretemp               12898  0 
pcspkr                 12579  0 
serio_raw              12931  0 
soundcore              13065  1 snd
i2c_i801               16870  0 
i7core_edac            22454  0 
iTCO_wdt               17081  0 
i2c_core               23876  6 i2c_i801,i2c_algo_bit,drm,drm_kms_helper,nouveau,adt7475
iTCO_vendor_support    12704  1 iTCO_wdt
edac_core              35258  3 i7core_edac
button                 12937  1 nouveau
wmi                    13243  2 mxm_wmi,nouveau
processor              28149  0 
ext4                  350763  3 
crc16                  12343  2 ext4,bluetooth
jbd2                   62115  1 ext4
mbcache                13114  3 ext4,ext2,ext3
cryptd                 14517  0 
aes_x86_64             16843  33 
aes_generic            33026  1 aes_x86_64
xts                    12645  16 
gf128mul               13048  1 xts
dm_crypt               22586  2 
dm_mod                 63645  14 dm_crypt
raid1                  30714  1 
md_mod                 87742  2 raid1
sg                     25874  0 
sr_mod                 21899  0 
sd_mod                 36136  9 
cdrom                  35401  1 sr_mod
crc_t10dif             12348  1 sd_mod
usbhid                 36418  0 
hid                    81372  1 usbhid
uhci_hcd               26865  0 
crc32c_intel           12747  0 
ahci                   24997  5 
firewire_ohci          35772  0 
libahci                22941  1 ahci
firewire_core          48449  1 firewire_ohci
libata                140630  2 libahci,ahci
crc_itu_t              12347  1 firewire_core
scsi_mod              162321  4 libata,sd_mod,sr_mod,sg
sky2                   45442  0 
ehci_hcd               40249  0 
fan                    12674  0 
usbcore               128741  4 ehci_hcd,uhci_hcd,usbhid
thermal                17383  0 
thermal_sys            18040  4 thermal,fan,processor,video
usb_common             12354  1 usbcore


-- System Information:
Debian Release: 7.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages cryptsetup depends on:
ii  cryptsetup-bin         2:1.4.3-4
ii  debconf [debconf-2.0]  1.5.49
ii  dmsetup                2:1.02.74-8
ii  libc6                  2.13-38+deb7u6

Versions of packages cryptsetup recommends:
ii  busybox                                 1:1.20.0-7
ii  console-setup                           1.88
ii  initramfs-tools [linux-initramfs-tool]  0.109.1
ii  kbd                                     1.15.3-9

Versions of packages cryptsetup suggests:
ii  dosfstools              3.0.13-1
ii  liblocale-gettext-perl  1.05-7+b1

-- debconf information:
  cryptsetup/prerm_active_mappings: true

Message #10 received at 774647@bugs.debian.org (full text, mbox, reply):

From: Lukasz Stelmach <stlman@poczta.fm>

To: 774647@bugs.debian.org

Subject: Re: Bug#774647: cryptsetup on initramfs does not support key files (resume swap on LVM)

Date: Sun, 18 Jan 2015 14:11:58 +0100

[Message part 1 (text/plain, inline)]

Hi,

The main reason reported this problem is that I want to enter
a single password to decrypt all my partitions. In such case
there is a way to work the problem around:

a) set the same password for all the devices you want initrd to decrypt,
b) use keyctl to cache the password.

My /etc/crypttab now looks like this:

-----8<-----
sda2_crypt UUID=e499987ab017 root_key luks,keyscript=decrypt_keyctl
sdb2_crypt UUID=c3b74b86b567 root_key luks,keyscript=decrypt_keyctl
-----8<-----

The procedure is described in the README.keyctl file.

http://anonscm.debian.org/viewvc/pkg-cryptsetup/cryptsetup/trunk/debian/README.keyctl?revision=977&view=co

-- 
Było mi bardzo miło.                   Twoje oczy lubią mnie
>Łukasz<                                     i to mnie zgubi  (c)SNL

[signature.asc (application/pgp-signature, attachment)]

Message #15 received at 774647@bugs.debian.org (full text, mbox, reply):

From: Guilhem Moulin <guilhem@guilhem.org>

To: 774647@bugs.debian.org

Subject: Re: cryptsetup on initramfs does not support key files (resume swap on LVM)

Date: Wed, 9 Dec 2015 06:14:10 +0100

[Message part 1 (text/plain, inline)]

Control: merge 776409 -1

Hi,

Yeah, it's because in the initramfs (before pivot_root) the key files
are relative to the real rootfs's mountpoint (/root).  Sergio Gelato has
found another workaround [0] using a dummy keyscript.

I'll see how to support this use case natively.  As documented in
crypttab(5), “the initramfs hook processes the root device, any resume
devices and any devices with the initramfs option set”, so indeed we
could safely include a keyfile if stored on an encrypted device that's
processed earlier.  AFAICT it's mostly a matter of getting the file's
mountpoint and finding out whether the device was already included in
conf.d/cryptroot.

Cheers,
-- 
Guilhem.

[0] https://bugs.debian.org/776409#74

[signature.asc (application/pgp-signature, inline)]

Message #28 received at 774647@bugs.debian.org (full text, mbox, reply):

From: Guilhem Moulin <guilhem@guilhem.org>

To: 774647@bugs.debian.org

Subject: Re: cryptsetup on initramfs does not support key files (resume swap on LVM)

Date: Sat, 12 Dec 2015 20:38:32 +0100

[Message part 1 (text/plain, inline)]

Here is a simple patch that adds keyfile support for non-root devices.
Ideally we would also warn the user if the key file is stored on an
unencrypted device, but that requires some code refactoring in the hook
file so it'll come in a later patch.

-- 
Guilhem.

[0001-Add-keyfile-support-for-non-root-devices.patch (text/x-diff, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #35 received at 774647@bugs.debian.org (full text, mbox, reply):

From: Jonas Meurer <jonas@freesources.org>

To: Guilhem Moulin <guilhem@guilhem.org>, 774647@bugs.debian.org

Subject: Re: [pkg-cryptsetup-devel] Bug#774647: cryptsetup on initramfs does not support key files (resume swap on LVM)

Date: Thu, 17 Dec 2015 10:55:06 +0100

[Message part 1 (text/plain, inline)]

Hi Guilhem,

Am 12.12.2015 um 20:38 schrieb Guilhem Moulin:
> Here is a simple patch that adds keyfile support for non-root devices.
> Ideally we would also warn the user if the key file is stored on an
> unencrypted device, but that requires some code refactoring in the hook
> file so it'll come in a later patch.

I like your idea to check whether the keyfile is on the rootfs for
resume and other non-rootfs devices that are processed during initramfs.

I've some comments and questions regarding your patch though. Have you
tested the patch already?

> 0001-Add-keyfile-support-for-non-root-devices.patch
> 
> 
> From efcd427201f7c0b6835e8bdedc559bd5623bc87e Mon Sep 17 00:00:00 2001
> From: Guilhem Moulin <guilhem@guilhem.org>
> Date: Sat, 12 Dec 2015 20:04:56 +0100
> Subject: [PATCH] Add keyfile support for non-root devices.
> 
> ---
>  debian/changelog                  |  3 +++
>  debian/initramfs/cryptroot-hook   | 31 ++++++++++++++++++++-----------
>  debian/initramfs/cryptroot-script |  3 +++
>  3 files changed, 26 insertions(+), 11 deletions(-)
> 
> diff --git a/debian/changelog b/debian/changelog
> index ea1f2c4..fa3c2c1 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -50,6 +50,9 @@ cryptsetup (2:1.7.0-1~mejo2) mejo-unstable; urgency=medium
>      storing keyfiles directly in the initrd. (closes: #786578)
>    * debian/initramfs/cryptroot-hook: display a warning for invalid source
>      devices (closes: #720515, #781955, #784435)
> +  * debian/initramfs/cryptroot-{hook,script}: add keyfile support for non-root
> +    devices.  A warning is printed if the keyfile itself in stored in the root
> +    partition.  (closes: #774647)
>  
>   -- Jonas Meurer <mejo@debian.org>  Thu, 10 Dec 2015 13:30:03 +0100
>  
> diff --git a/debian/initramfs/cryptroot-hook b/debian/initramfs/cryptroot-hook
> index 4e42086..f1bda44 100644
> --- a/debian/initramfs/cryptroot-hook
> +++ b/debian/initramfs/cryptroot-hook
> @@ -232,11 +232,12 @@ get_lvm_deps() {
>  }
>  
>  get_device_opts() {
> -	local target source link extraopts rootopts opt key
> +	local target source link extraopts rootopts opt key isrootdev
>  	target="$1"
>  	extraopts="$2"
> +	isrootdev="$3"

What's the reason for introducing the isrootdev variable? Why not use
the "rootdev" option that's already there? Honestly, I don't get it.
Probably I miss something, though ;)

*/ You set isrootdev=n at the beginning of add_device(). If the device
   is an underlying device for rootfs , then rootdev is added to $opts
   (old) and now, isrootdev=y is set additionally (new). The value of
   isrootdev is given to get_device_opts() as $3.
*/ At the start of get_device_opts(), isrootdev is set to the value of
   $3. If the opt "rootdev" is set, then isrootdev=y is set.
*/ Up to now, the variable $isrootdev is only set to 'y' in exactly the
   same situations as that the opt "rootdev" is set as well. If rootdev
   is not set in $opts, then $isroodev=n. So in my eyes, the opt
   "rootdev" and the variable $isrootdev are consistent.
*/ Later in get_device_opts() when the keyfiles are processed, you
   check for $isrootdev and warn if it $isrootdev!=n. Why not simply
   search for "rootdev" in $OPTIONS instead? See below for a suggestion.

>  	KEYSCRIPT=""
> -	KEYFILE=""
> +	KEYFILE="" # key file to copy in the initramfs image
>  	CRYPTHEADER=""
>  	OPTIONS=""
>  
> @@ -340,6 +341,7 @@ get_device_opts() {
>  				OPTIONS="$OPTIONS,$opt"
>  				;;
>  			rootdev)
> +				isrootdev=y

See above.

>  				OPTIONS="$OPTIONS,$opt"
>  				;;
>  			*)

> @@ -371,8 +373,17 @@ get_device_opts() {
>  				key="/cryptroot-keyfiles/${target}.key"
>  				;;
>  			*)
> -				echo "cryptsetup: WARNING: target $target uses a key file, skipped" >&2
> -			   	return 1
> +				if [ "$isrootdev" != n ]; then

See above. I think, that the following would be sufficient:

if echo "$OPTIONS" | grep -q "\brootdev\b"; then

> +					echo "cryptsetup: WARNING: root target $target uses a key file, skipped" >&2
> +					return 1;
> +				elif [ "$(stat -Lc %m -- "$key" 2>/dev/null)" != / ]; then

Would need to stat against the canonical file (e.g. after readlink)
here. Otherwise, the keyfile path can be a link on the rootfs that
points to another partition. Should be as easy as adding:

keylink=$(readlink -e "$dev")

just before the case selection and running stat against $keylink.

> +					echo "cryptsetup: WARNING: $target's key file $key is not on the root FS, skipped" >&2
> +					return 1;
> +				else
> +					OPTIONS="$OPTIONS,keyscript=cat-rootmnt" # prefix $rootmnt in local-block
> +					# TODO: warn if the keyfile is not stored on an encrypted device
> +				fi

No need for the TODO in my eyes. We only get here, if the key is stored
on the rootfs. In this case, we don't fiddle around with the keyfile at
all. All we do, is change the path to the keyfile in cryptroot-script,
so the keyfile itself is not touched by us at all.

Sure, it would be nice to warn the user if she stores the keyfile on an
unencrypted root fs, but then this is just one more corner case where a
user implements an uncommon custom setup in an unsecure fashion, and we
cannot check against all those corner cases anyway.

> +				key=$(readlink -f "$key")

Would be key="$keylink" then.

>  				;;
>  		esac
>  	fi

> @@ -455,10 +466,11 @@ canonical_device() {
>  }
>  
>  add_device() {
> -	local node nodes opts lastopts i count
> +	local node nodes opts lastopts i count isrootdev
>  	nodes="$1"
>  	opts=""     # Applied to all nodes
>  	lastopts="" # Applied to last node
> +	isrootdev=n

See above.

>  
>  	if [ -z "$nodes" ]; then
>  		return 0
> @@ -466,11 +478,8 @@ add_device() {
>  
>  	# Flag root device
>  	if echo "$rootdevs" | grep -q "\b$nodes\b"; then
> -		if [ -z "$opts" ]; then
> -			opts="rootdev"
> -		else
> -			opts="$opts,rootdev"
> -		fi
> +		opts="${opts:+$opts,}rootdev"

I like :)

> +		isrootdev=y

See above.

>  	fi
>  
>  	# Check that it is a node under /dev/mapper/
> @@ -509,7 +518,7 @@ add_device() {
>  		fi
>  
>  		# Get crypttab root options
> -		if ! get_device_opts "$node" "$opts"; then
> +		if ! get_device_opts "$node" "$opts" "$isrootdev"; then

See above.

>  			continue
>  		fi
>  		echo "$OPTIONS" >>"$DESTDIR/conf/conf.d/cryptroot"
> diff --git a/debian/initramfs/cryptroot-script b/debian/initramfs/cryptroot-script
> index e450580..877161a 100644
> --- a/debian/initramfs/cryptroot-script
> +++ b/debian/initramfs/cryptroot-script
> @@ -304,6 +304,9 @@ setup_mapping()
>  				cryptkeyscript="/lib/cryptsetup/askpass"
>  				cryptkey="Please unlock disk $diskname: "
>  			fi
> +		elif [ "$cryptkeyscript" = "cat-rootmnt" ]; then
> +			cryptkeyscript=cat
> +			cryptkey="${rootmnt}${cryptkey}"
>  		fi
>  
>  
> -- 2.6.4

Cheers
 jonas

[signature.asc (application/pgp-signature, attachment)]

Message #40 received at 774647@bugs.debian.org (full text, mbox, reply):

From: Guilhem Moulin <guilhem@guilhem.org>

To: Jonas Meurer <jonas@freesources.org>

Cc: 774647@bugs.debian.org

Subject: Re: [pkg-cryptsetup-devel] Bug#774647: cryptsetup on initramfs does not support key files (resume swap on LVM)

Date: Sat, 19 Dec 2015 19:20:06 +0100

[Message part 1 (text/plain, inline)]

Hi,

On Thu, 17 Dec 2015 at 10:55:06 +0100, Jonas Meurer wrote:
> I've some comments and questions regarding your patch though. Have you
> tested the patch already?

Yes, but only on a resume device (and without LVM).  (But I don't see
how the same wouldn't work for other devices and/or LVM.)
 
> What's the reason for introducing the isrootdev variable? Why not use
> the "rootdev" option that's already there? Honestly, I don't get it.
> Probably I miss something, though ;)

I only wanted to avoid parsing the $OPTIONS string :-P  But indeed it's
easier to grep through $OPTIONS.  And not more error prone if we assume
that crypttab fields don't contain blanks or commas.

> See above. I think, that the following would be sufficient:
> 
> if echo "$OPTIONS" | grep -q "\brootdev\b"; then

As pointed out on IRC, word delimiters are error prone since
‘key=/path/to/rootdev.key’ would match, for instance.  But

    if echo "$OPTIONS" | grep -q "^(.*,)?rootdev(,.*)?$"; then

looks fine.

>> +					echo "cryptsetup: WARNING: root target $target uses a key file, skipped" >&2
>> +					return 1;
>> +				elif [ "$(stat -Lc %m -- "$key" 2>/dev/null)" != / ]; then
> 
> Would need to stat against the canonical file (e.g. after readlink)
> here. Otherwise, the keyfile path can be a link on the rootfs that
> points to another partition. Should be as easy as adding:
>
> keylink=$(readlink -e "$dev")
> 
> just before the case selection and running stat against $keylink.

Oh, right, stat's -L flag deferences symlink, but doesn't take the
canonical path, indeed.

> No need for the TODO in my eyes. We only get here, if the key is stored
> on the rootfs. In this case, we don't fiddle around with the keyfile at
> all. All we do, is change the path to the keyfile in cryptroot-script,
> so the keyfile itself is not touched by us at all.
> 
> Sure, it would be nice to warn the user if she stores the keyfile on an
> unencrypted root fs, but then this is just one more corner case where a
> user implements an uncommon custom setup in an unsecure fashion, and we
> cannot check against all those corner cases anyway.

Makes sense, fixed and new patch enclosed.

Cheers,
-- 
Guilhem.

[0001-Add-keyfile-support-for-non-root-devices.patch (text/x-diff, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #45 received at 774647@bugs.debian.org (full text, mbox, reply):

From: Guilhem Moulin <guilhem@guilhem.org>

To: Jonas Meurer <jonas@freesources.org>, 774647@bugs.debian.org

Subject: Re: [pkg-cryptsetup-devel] Bug#774647: cryptsetup on initramfs does not support key files (resume swap on LVM)

Date: Sat, 19 Dec 2015 19:35:55 +0100

[Message part 1 (text/plain, inline)]

Sorry, typo :-P

-- 
Guilhem.

[0001-Add-keyfile-support-for-non-root-devices.patch (text/x-diff, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #50 received at 774647@bugs.debian.org (full text, mbox, reply):

From: Guilhem Moulin <guilhem@guilhem.org>

To: Jonas Meurer <jonas@freesources.org>, 774647@bugs.debian.org

Subject: Re: [pkg-cryptsetup-devel] Bug#774647: cryptsetup on initramfs does not support key files (resume swap on LVM)

Date: Sun, 20 Dec 2015 00:39:06 +0100

[Message part 1 (text/plain, inline)]

Grmbl, in fact I didn't test it properly: the resume device was mounted
by systemd not by the initramfs image.  This seems to be due to the
current init which requires all node devices to be present before the
rootfs is being mounted, as found in initramfs-tools(8):

	local-top OR nfs-top After these scripts have been executed, the root
	device node is expected to be present (local) or the network interface is
	expected to be usable (NFS).

	local-block These scripts are called with the name of a local block
	device. After these scripts have been executed, that device node should be
	present. If the local-top or local-block scripts fail to create the wanted
	device node, the local-block scripts will be called periodically to try
	again.

	local-premount OR nfs-premount are run after the sanity of the root device
	has been verified (local) or the network interface has been brought up
	(NFS), but before the actual root fs has been mounted.

	local-bottom OR nfs-bottom are run after the rootfs has been mounted
	(local) or the NFS root share has been mounted.

So I guess we'll have to mount the roofs read-only in a temporary
directory, and unmount it afterwards.

-- 
Guilhem.

[signature.asc (application/pgp-signature, inline)]

Message #55 received at 774647@bugs.debian.org (full text, mbox, reply):

From: Guilhem Moulin <guilhem@guilhem.org>

To: 774647@bugs.debian.org

Subject: Re: [pkg-cryptsetup-devel] Bug#774647: cryptsetup on initramfs does not support key files (resume swap on LVM)

Date: Thu, 15 Sep 2016 15:34:42 +0200

[Message part 1 (text/plain, inline)]

Control: unmerge -1
Control: tag -1 - patch
Control: retitle -1 can't a use key file stored on an encrypted rootfs to unlock the resume device at initramfs stage
Control: severity -1 wishlist
Control: tag 776409 pending

I just added support for unlocking devices at initramfs stage using a
key file stored on the encrypted root FS.  However the resume device
won't be unlocked this way since the resume boot script is currently run
before mounting the root FS.

-- 
Guilhem.

[signature.asc (application/pgp-signature, inline)]

Message #76 received at 774647@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.org>

To: 774647@bugs.debian.org

Subject: Re: can't a use key file stored on an encrypted rootfs to unlock the resume device at initramfs stage

Date: Sun, 26 Mar 2023 00:15:21 +0100

Hey.

I recently considered to do the same, i.e.:
- have a passphrase only for the dm-crypt encrypted rootfs
- have a separate dm-crypt encrypted swap device for hibernate only
- use a high-entropy key-file on the rootfs to decrypt the swap device


My understanding of the initramfs-tools boot is as follows:
init-top
...
local-top => here cryptroot opens ("decrypts") the root- and resume-
             device as well as any with "initramfs"-option in crypttab
local-bottom => it retries the same here
local-premount => here, none of these devices has been mounted, yet
                  also here, the resume happens, at which point
                  the system is completely replaced, the initramfs used
                  just before for booting into the resume no longer
                  exists, no mounting of the devices will take place,
                  no pivot_root either
                  (none of this is anyway necessary, as the resumed
                  system has all that already done)

So the only way to get a key-file within the (not mounted) rootfs after
local-top/bottom but before the resume in local-premount would be to
actually mount the root fs before.

This is however pretty dangerous.
Even if the mounting is done read-only, filesystems may perform changes
(at least btrfs does, and I think ext4 may do so too).


There was recently [0], where someone mounted the root-fs in-between
suspend and resume and got corruptions.
While it was argued that the filesystem was frozen at suspend and that
btrfs would *try* to detect (since 6.2) whether it was mounted in-
between,... it was also argued that caching (in the resumed system) may
cause corruptions.


The blockdevice would need to be blockdev --setro first, but even that
may be more complex than one might think:
Consider e.g. multi-device filesystems (again e.g. btrfs), where the
other devices are auto-detected via UUID.


So IMO, this feature cannot be safely implemented.


Maybe the only way to do it safely was a hack:
- create a swapfile in the rootfs (this is anyway required to be not
  moved)
- get it's physical offest into the device (beware: for btrfs special
  commands are needed for that)
- let cryptroot read the key raw from that offest

But, again, quite ugly and hacky.


Cheers,
Chris.



[0] https://lore.kernel.org/linux-btrfs/ba9fb1c9-ccbc-4b93-92f9-a8c17ffab7f6@business-insulting.de/

Message #81 received at 774647@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.org>

To: 774647@bugs.debian.org

Cc: Guilhem Moulin <guilhem@debian.org>

Subject: Re: can't a use key file stored on an encrypted rootfs to unlock the resume device at initramfs stage

Date: Mon, 27 Mar 2023 16:29:40 +0200

Hey.

I rather think now that even my hack with the swapfile isn't really
save.
The idea with that was that it's just the file, but not activated as
swap of course. But who knows for sure that in this case the file is
never moved.


Anyway, @Guilhem, would you agree to close this as wontfix and add a
README.x entry that describes why - with hibernation/resume - the key
file cannot safely be loaded from a filesystem that is hibernated, too?

Not sure whether to better put it in README.initramfs (yes it happens
in that phase) or README.Debian (in principle a user could just hack
something together on his own with the same issue and not even install
cryptsetup-initramfs).


Cheers,
Chris.

Send a report that this bug log contains spam.