Bug#1062756: cryptsetup-initramfs: cryptkeyctl script fails to discover decrypt_keyctl even when present

[abrasamji]

Package: cryptsetup-initramfs
Version: 2:2.6.1-4~deb12u1
Severity: important
X-Debbugs-Cc: debian...@simplelogin.com

Dear Maintainer,


Not sure what is happening here, but the /usr/share/initramfs-tools/hooks/cryptkeyctl script is no longer properly finding decrypt_keyctl in the initramfs temp file during initramfs build.

This script is meant to be called for usage with decrypt_keyctl in /etc/crypttab, a script to automatically pass the password of one LUKS volume to another during bootup. This script is provided by cryptsetup.
The consequence of this error is a failure to unlock any disks at boot-time that uses the decrypt_keyctl keyscript, and a failure to boot if the device is a root device or otherwise needed to boot.

update-initramfs log excerpt with set -x:

Calling hook cryptkeyctl
+ PREREQ=cryptroot
+ . /usr/share/initramfs-tools/hook-functions
+ [ ! -x /tmp/user/0/mkinitramfs_LhQz6c/lib/cryptsetup/scripts/decrypt_keyctl ]
+ exit 0


A check with ls -la while update-initramfs was running, prior to cryptkeyctl being executed, in order to prove it's presence:

/tmp/user/0/mkinitramfs_LhQz6c/usr/lib/cryptsetup/scripts:
total 4
drwxr-xr-x 2 root root 60 Feb 2 17:44 .
drwxr-xr-x 3 root root 100 Feb 2 17:44 ..
-rwxr-xr-x 1 root root 2042 Apr 20 2023 decrypt_keyctl



I changed the '-x' flag in the if statement to a '-s' flag. This fixed it and I don't know why, and I don't know if its a bug in initramfs, dash, or cryptsetup or something else.


Functioning code with the -s in the cryptkeyctl hook:

if [ ! -s "$DESTDIR/lib/cryptsetup/scripts/decrypt_keyctl" ]; then
exit 0
fi

Thank you for your time.

-- Package-specific info:

-- System Information:
Debian Release: 12.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable'), (100, 'bookworm-fasttrack')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.5-hardened1-stripes-1-s-3.32 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_RANDSTRUCT
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cryptsetup-initramfs depends on:
ii busybox 1:1.35.0-4+b3
ii cryptsetup 2:2.6.1-4~deb12u1
ii debconf [debconf-2.0] 1.5.82
ii initramfs-tools [linux-initramfs-tool] 0.142

Versions of packages cryptsetup-initramfs recommends:
ii console-setup 1.221
ii kbd 2.5.1-1+b1

Version of dash

ii dash 0.5.12-2

cryptsetup-initramfs suggests no packages.

-- debconf information excluded

[debian...@simplelogin.com]

In case anyone else is having this issue, error appears to the end user as:

decrypt_keyctl: empty input from stdin

keyctl: command not found

Cryptsetup then gives an error about the password being incorrect.

[Guilhem Moulin]

Control: tag -1 moreinfo

Hi,

On Fri, 02 Feb 2024 at 18:44:43 -0500, abrasamji wrote:
> update-initramfs log excerpt with set -x:
>
> Calling hook cryptkeyctl
> + PREREQ=cryptroot
> + . /usr/share/initramfs-tools/hook-functions
> + [ ! -x /tmp/user/0/mkinitramfs_LhQz6c/lib/cryptsetup/scripts/decrypt_keyctl ]
> + exit 0
>
> A check with ls -la while update-initramfs was running, prior to
> cryptkeyctl being executed, in order to prove it's presence:
>
> /tmp/user/0/mkinitramfs_LhQz6c/usr/lib/cryptsetup/scripts:
> total 4
> drwxr-xr-x 2 root root 60 Feb 2 17:44 .
> drwxr-xr-x 3 root root 100 Feb 2 17:44 ..
> -rwxr-xr-x 1 root root 2042 Apr 20 2023 decrypt_keyctl
>
> I changed the '-x' flag in the if statement to a '-s' flag. This fixed
> it and I don't know why, and I don't know if its a bug in initramfs,
> dash, or cryptsetup or something else.

Seems like your update-initramfs is running under TMPDIR=/tmp/user/0, is
is perhaps mounted with the ‘noexec’ flag set?

That would cause `test -x` to fail on an existing path with the exec bit
set, and per mkinitramfs(8) this not supported:

ENVIRONMENT

mkinitramfs honours the TMPDIR environment variable. If set, it
uses subdirectories in the given directory to create its
temporary working directories. Else it uses /var/tmp as default
value for that purpose. The given directory should be on a
filesystem which allows the execution of files stored there, i.e.
should not be mounted with the noexec mount option.

--
Guilhem.

[debian...@simplelogin.com]

That does indeed seem to be the case.

It appears that my distro activated a temporary directory override recently, and I already had /tmp mounted as NOEXEC.

Bug report for my distro for anyone that comes across this:
https://github.com/Kicksecure/security-misc/issues/198

Thank you

[Guilhem Moulin]

On Wed, 14 Feb 2024 at 13:58:00 +0000, Patrick Schleizer wrote:
> This is not a bug in a downstream distribution.
> […]
> Could this be fixed in Debian please?

I don't see how this would be a bug in cryptsetup-initramfs when
mkinitramfs(8) explicitely says DESTDIR should not be mounted with the