keyscript option in crypttab not implemented

[Jani Uusitalo]

The setup for unlocking an encrypted volume during boot using (only) a keyfile (on a detachable USB drive) usually calls for a keyscript to be specified as one of the encrypted volume's options. But with systemd, such encrypted volumes can only be unlocked during boot by typing in a passphrase.

Steps to reproduce:
1. Have a LUKS encrypted volume.
2. Have said volume specified in /etc/crypttab, with keyscript= option pointing to your script for outputting the unlocking key.
3. Boot.

What I expect to happen:
To have the volume unlocked by the script at boot time without manual intervention.

What happens instead:
Plymouth shows a prompt to enter a valid passphrase for the volume.

Workarounds:
Apparently the options for unlocking encrypted drives, including keyscript, can also be specified at the kernel command-line, without crypttab, and according to yaantc at Hacker News [1] this can be used to work around the issue. I haven't personally tried this.

* [1] https://news.ycombinator.com/item?id=8477913

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: systemd 219-7ubuntu4
ProcVersionSignature: Ubuntu 3.19.0-15.15-generic 3.19.3
Uname: Linux 3.19.0-15-generic x86_64
ApportVersion: 2.17.2-0ubuntu1
Architecture: amd64
CurrentDesktop: Unity
Date: Sat May 2 15:39:07 2015
InstallationDate: Installed on 2014-10-18 (196 days ago)
InstallationMedia: Ubuntu 14.10 "Utopic Unicorn" - Alpha amd64 (20140923)
MachineType: ASUSTeK COMPUTER INC. UX32A
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.19.0-15-generic.efi.signed root=UUID=2185885c-b860-49a8-973f-fa3b52d3eecf ro quiet splash vt.handoff=7
SourcePackage: systemd
UpgradeStatus: Upgraded to vivid on 2015-04-23 (8 days ago)
dmi.bios.date: 01/29/2013
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: UX32A.214
dmi.board.asset.tag: ATN12345678901234567
dmi.board.name: UX32A
dmi.board.vendor: ASUSTeK COMPUTER INC.
dmi.board.version: 1.0
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: ASUSTeK COMPUTER INC.
dmi.chassis.version: 1.0
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrUX32A.214:bd01/29/2013:svnASUSTeKCOMPUTERINC.:pnUX32A:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnUX32A:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:
dmi.product.name: UX32A
dmi.product.version: 1.0
dmi.sys.vendor: ASUSTeK COMPUTER INC.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Eduards Bezverhijs (mjasnik)]

I was just experimenting with this and about to create a bug, but someone already did, very good :)

I set up some "home brew" logging and it seems passdev is never called, instead systemd is waiting for device which is specified as source for the key, second option in crypttab.

When I boot up using upstart, then all is fine and device gets unlocked.

[Alberto Salvia Novella (es20490446e)]

@ Martin Pitt

"Triaged" doesn't only mean that we think the bug is genuine, but also that we have performed all these checks:
<https://wiki.ubuntu.com/One%20Hundred%20Papercuts/Triage>

[GOo (goo)]

I have three luks partitions in /etc/crypttab ( /, /home/, /var) all of them with a keyscript definition.
Systemd doesn't unlock /var and /home, whereas the root partition gets unlocked without problems, so it doesn't seem that the keyscript definition is not implemented.
I set up a workaround by enabling a second key slot for /var and /home filled with a standard passphrase.
Actually systemd asks for the passphrase only once and uses the same entered passphrase for both partitions.

Results:
/ is normally unlocked by calling its associated keyscript.
/var and /home are unloked with a standard passphrase (the same for both partitions).

[Martin Pitt (pitti)]

GOo [2015-05-04 16:18 -0000]:
> I have three luks partitions in /etc/crypttab ( /, /home/, /var) all
> of them with a keyscript definition. Systemd doesn't unlock /var
> and /home, whereas the root partition gets unlocked without
> problems, so it doesn't seem that the keyscript definition is not
> implemented.

Explanation: The root partition is unlocked in initramfs with
cryptsetup's own scripts. The others are unlocked in the running
system, with systemd's implementation which is lacking support for
keyscript.

[GOo (goo)]

Thank you for the explanation. I forgot about the root partition being unlocked from within initramfs.

[TJ (tj)]

This really needs to be solved. Unlocking secure systems that use some external key device that requires a specific helper script to access is a significant use case.

According to the Debian bug report discussion it seems that upstream systemd aren't prepared to finish their replacement implementation of cryptsetup init scripts without some kind of major new generic functionality.

Ccan we workaround that by disabling systemd-cryptsetup and use the existing cryptsetup functionality?

[TJ (tj)]

The latest discussion about this on the systemd mailing-list:

http://lists.freedesktop.org/archives/systemd-devel/2014-August/022014.html

"Also note that we really should redesign the entire scheme around the
kernel keyring as only transport for the keys (and the bus for
signalling). I am a bit conservative in changing here too much for now,
because we really should figure out that bit first."

[Dan Streetman (ddstreet)]

please reopen if this is still an issue

[TJ (tj)]

This really should not be marked Invalid since it represents a very real regression on recommended and documented functionality that many installs using LUKS rely upon. Workarounds of varying security quality abound as a result instead of a single, well designed and integrated solution.

Indeed, in December 2020 Lennart Poettering created a simple patch for this by extending the cryptsetup code to read an AF_SOCKET [1] and recommended linking that with a system-service that sets StandardOutput=socket [2][3] where the key data can be read from.

[1] hasn't been merged into systemd as yet but with some additional push upstream that could likely happen.

[1] https://github.com/poettering/systemd/commit/e2c2f868b28f1445e061bf7eb475b0c49efe3ac2

[2] https://github.com/systemd/systemd/pull/3007#issuecomment-710212323

[3] https://github.com/systemd/systemd/pull/3007#issuecomment-713860129

[TJ (tj)]

Update: Lennart's AF_SOCKET solution was added to systemd v248 in:

commit e2c2f868b28f1445e061bf7eb475b0c49efe3ac2
Author: Lennart Poettering <email address hidden>
Date: Wed Nov 4 17:24:53 2020 +0100

    cryptsetup: port cryptsetup's main key file logic over to read_full_file_full()

    Previously, we'd load the file with libcryptsetup's calls. Let's do that
    in our own, so that we can make use of READ_FULL_FILE_CONNECT_SOCKET,
    i.e. read in keys via AF_UNIX sockets, so that people can plug key
    providers into our logic.

    This provides functionality similar to Debian's keyscript= crypttab
    option (see → #3007), as it allows key scripts to be run as socket
    activated services, that have stdout connected to the activated socket.
    In contrast to traditional keyscript= support this logic runs stuff out
    of process however, which is beneficial, since it allows sandboxing and
    similar.