Bug#618862: systemd: ignores keyscript in crypttab
Mourad De Clerck
Version: 19-1
Severity: normal
Hi,
my root and swap partition are encrypted with cryptsetup; root uses a custom
keyscript and swap uses the cryptsetup-provided "decrypt_derived" keyscript.
systemd seems to be unable to work with keyscripts at all, and requires
password input for every volume that wasn't activated already. Luckily, my
root FS is activated by the initramfs.
I don't want to have to type in a password for every encrypted volume: on
some of my machines this would mean having to type five or more passwords on
boot.
Is there any way of using keyscripts or some equivalent with systemd?
FYI, some (abbreviated) info on my machine.
/etc/fstab:
/dev/mapper/root / ext3 relatime,user_xattr,errors=remount-ro 0 1
/dev/sda1 /boot ext3 noatime 0 2
/dev/mapper/swap none swap sw 0 0
/etc/crypttab:
root UUID=... /dev/... luks,keyscript=/usr/local/lib/cryptsetup/scripts/decrypt_dev
swap UUID=... root luks,keyscript=/lib/cryptsetup/scripts/decrypt_derived
/var/log/syslog:
systemd-initctl[10973]: Received environment initctl request. This is not implemented in systemd.
systemd-fsck[452]: root: clean, 444366/13107200 files, 47184313/52427870 blocks
systemd-cryptsetup[735]: Encountered unknown /etc/crypttab option 'keyscript=/usr/local/lib/cryptsetup/scripts/decrypt_dev', ignoring.
systemd-cryptsetup[735]: Volume root already active.
systemd-cryptsetup[781]: Password file path root is not absolute. Ignoring.
systemd-cryptsetup[781]: Encountered unknown /etc/crypttab option 'keyscript=/lib/cryptsetup/scripts/decrypt_derived', ignoring.
systemd-fsck[738]: /dev/sda1: clean, 255/65952 files, 57208/263056 blocks
systemd-cryptsetup[781]: Invalid packet
systemd-cryptsetup[781]: Timed out
systemd-cryptsetup[781]: Failed to query password: Timer expired
systemd-cryptsetup[1102]: Password file path root is not absolute. Ignoring.
systemd-cryptsetup[1102]: Encountered unknown /etc/crypttab option 'keyscript=/lib/cryptsetup/scripts/decrypt_derived', ignoring.
systemd-cryptsetup[1102]: Timed out
systemd-cryptsetup[1102]: Failed to query password: Timer expired
systemd-cryptsetup[1399]: Password file path root is not absolute. Ignoring.
systemd-cryptsetup[1399]: Encountered unknown /etc/crypttab option 'keyscript=/lib/cryptsetup/scripts/decrypt_derived', ignoring.
systemd-cryptsetup[1399]: Timed out
systemd-cryptsetup[1399]: Failed to query password: Timer expired
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.38-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages systemd depends on:
ii libaudit0 1.7.13-1+b2 Dynamic library for security audit
ii libc6 2.11.2-13 Embedded GNU C Library: Shared lib
ii libcap2 1:2.20-1 support for getting/setting POSIX.
ii libcryptsetup1 2:1.2.0-2 libcryptsetup shared library
ii libdbus-1-3 1.4.6-1 simple interprocess messaging syst
ii libpam0g 1.1.2-2 Pluggable Authentication Modules l
ii libselinux1 2.0.96-1 SELinux runtime shared libraries
ii libudev0 166-1 libudev shared library
ii util-linux 2.17.2-9.1 Miscellaneous system utilities
Versions of packages systemd recommends:
ii libpam-systemd 19-1 system and service manager - PAM m
Versions of packages systemd suggests:
ii systemd-gui 19-1 system and service manager - GUI
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Marc Haber
thanks
On Sat, Mar 19, 2011 at 03:40:25AM +0100, Mourad De Clerck wrote:
> my root and swap partition are encrypted with cryptsetup; root uses a custom
> keyscript and swap uses the cryptsetup-provided "decrypt_derived" keyscript.
> systemd seems to be unable to work with keyscripts at all, and requires
> password input for every volume that wasn't activated already. Luckily, my
> root FS is activated by the initramfs.
>
> I don't want to have to type in a password for every encrypted volume: on
> some of my machines this would mean having to type five or more passwords on
> boot.
12 LVs are like 300 bytes of binary gibberish long. Typing them during
system boot is kind of out of the question.
Missing keyscript support is a total surprise to me, which breaks my
three most important systems. I am thus raising the severity of this
bug to important. It could also be higher, since it breaks the system.
I am also concerned since I remember well analyzing the scripts in the
initrd when I developed my cryptdisk setup. Since these mechanics seem
to have moved into systemd, I have learned that I would not have been
able to find out what's going on during system boot if we had systemd
back then. I don't like that idea at all.
Management Summary: Please make keyscript work.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 31958061
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062
Evgeni Golov
On Sat, Mar 19, 2011 at 03:40:25AM +0100, Mourad De Clerck wrote:
> keyscript and swap uses the cryptsetup-provided "decrypt_derived" keyscript.
> systemd seems to be unable to work with keyscripts at all, and requires
> password input for every volume that wasn't activated already. Luckily, my
> root FS is activated by the initramfs.
with LVM on it. root and swap are LVs. The only "interesting" part is
the `passdev` keyscript from pkg:cryptsetup, which mounts a device and
reads a file on that device as the actual key.
With the upgrade from 204-14 to 208-6, my system shows an interesting
behaviour. The crypt is properly opened in initrd, but then systemd
decides to reopen it, totally failing to use the keyscript and its
"weird" keyfile naming, resulting in a timeout:
Jul 18 20:42:29 nana systemd[1]: Expecting device dev-disk-by\x2dlabel-usbext3:-keyfile\x2dnana.luks:10.device...
Jul 18 20:43:59 nana systemd[1]: Job dev-disk-by\x2dlabel-usbext3:-keyfile\x2dnana.luks:10.device/start timed out.
Jul 18 20:43:59 nana systemd[1]: Timed out waiting for device dev-disk-by\x2dlabel-usbext3:-keyfile\x2dnana.luks:10.device.
Jul 18 20:43:59 nana systemd[1]: Dependency failed for Cryptography Setup for nana-crypt.
Jul 18 20:43:59 nana systemd[1]: Dependency failed for Encrypted Volumes.
My crypttab:
# <target name> <source device> <key file> <options>
nana-crypt UUID=ffff.... /dev/disk/by-label/usbext3:/keyfile-nana.luks:10 luks,discard,keyscript=/lib/cryptsetup/scripts/passdev,tries=1
My fstab:
LABEL=nana-boot /boot ext4 noatime,discard 0 0
/dev/mapper/nana--vg01-nana--root / ext4 noatime,discard,errors=remount-ro 0 1
/dev/mapper/nana--vg01-nana--home /home ext4 noatime,discard,errors=remount-ro 0 1
/dev/mapper/nana--vg01-nana--swap none swap defaults 0 0
Greets
Evgeni
Michel Messerschmidt
> systemd's generator
>
> This worked great... until you try to add another partition to crypttab.
> Since the cryptroot in initrd only does root, but luks=no disables all
> others.
>
> Is there any clean solution that recognizes the granularity? Maybe one way
> is to put all encrypted filesystems loaded via initramfs?
Not a clean solution, but a workaround for root partitions using a keyscript.
Let systemd handle encrypted partitions via crypttab (i.e. don't use luks=no).
But exclude the root partition by masking the generated unit.
Example
---------
My crypttab contains (among other entries):
root_crypt UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /dev/disk/by-uuid/yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy:/keys/root luks,keyscript=passdev
systemd will dynamically generate service units for all partitions in crypttab:
$ ls -l /run/systemd/generator/systemd-cryptsetup*
-rw-r--r-- 1 root root 867 Feb 2 16:31 /run/systemd/generator/systemd-cryptsetup@home_crypt.service
-rw-r--r-- 1 root root 1103 Feb 2 16:31 /run/systemd/generator/systemd-cryptsetup@root_crypt.service
-rw-r--r-- 1 root root 865 Feb 2 16:31 /run/systemd/generator/systemd-cryptsetup@var_crypt.service
Whenever systemd tries to start systemd-cryptsetup@root_crypt.service during boot, it will timeout and fail.
Feb 02 13:52:39 host systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-yyyyyyyy\x2dyyyy\x2dyyyy\x2dyyyy\x2dyyyyyyyyyyyy:-keys-root.device.
Feb 02 13:52:39 host systemd[1]: Dependency failed for Cryptography Setup for root_crypt.
Feb 02 13:52:39 host systemd[1]: Dependency failed for Local Encrypted Volumes.
Feb 02 13:52:39 host systemd[1]: cryptsetup.target: Job cryptsetup.target/start failed with result 'dependency'.
Feb 02 13:52:39 host systemd[1]: systemd-cryptsetup@root_crypt.service: Job systemd-cryptsetup@root_crypt.service/start failed with result 'dependency'.
But the following command will mask this unit, so that systemd will not attempt to start at all:
systemctl mask systemd-cryptsetup@root_crypt.service
Afterwards, my system boots without timeout and all encrypted partitions are available.
HTH,
Michel
--
Security is not a product and not a process. Security is an emotion.
Michael Niewöhner
I stumbled on this, too but I have a work-around for at least 'decrypt_keyctl'.
systemd uses systemd-cryptsetup -> systemd-ask-password -> linux keyring.
The keyring can be modified by keyctl just as 'decrypt_keyctl' does.
As I wanted to use 'decrypt_keyctl' for unlocking root and data with the same
password, I applied this patch:
--- /lib/cryptsetup/scripts/decrypt_keyctl.distrib 2017-05-09
13:50:59.000000000 +0200
+++ /lib/cryptsetup/scripts/decrypt_keyctl 2018-08-04 21:34:01.130979945
+0200
@@ -24 +24 @@ die()
-ID_="cryptkey-$1"
+ID_="cryptsetup"
My entries in crypttab are these:
crypt_sys /dev/zpool_sys/zvol_sys none luks,discard,keyscript=decrypt_keyctl
crypt_data /dev/zpool_data/zvol_data none luks,discard,keyscript=decrypt_keyctl
Now cryptsetup-initramfs unlocks my root device and decrypt_keyctl caches the
password to linux keyring with desc=cryptsetup.
Systemd then reads the key from keyring with desc=cryptsetup and unlocks my data
device! :-)
That keyring caching could be easily added to all other keyscripts to make
systemd unlock work ;-)
Best regards
Michael
Thomas Koch
It would be nice, if somebody could celebrate the 10 years anniversary of this bug with a summary of the current state and outlook?
Thank you! Thomas
Michael Biebl
>
> It would be nice, if somebody could celebrate the 10 years anniversary of this bug with a summary of the current state and outlook?
support keyscripts as is.
For a more detailed answer, please see
https://github.com/systemd/systemd/pull/3007
specifically
https://github.com/systemd/systemd/pull/3007#issuecomment-710212323
Maybe you can hack something together using this alternative interface.
Michael