keyscript option in crypttab not implemented

Bug #1451032 reported by Jani Uusitalo on 2015-05-02
84
This bug affects 16 people
Affects Status Importance Assigned to Milestone
systemd (Debian)
Confirmed
Unknown
systemd (Ubuntu)
Medium
Unassigned

Bug Description

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.

Jani Uusitalo (uusijani) wrote :
description: updated
Changed in systemd (Debian):
status: Unknown → Confirmed
Launchpad Janitor (janitor) wrote :

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

Changed in systemd (Ubuntu):
status: New → Confirmed
Eduards Bezverhijs (mjasnik) wrote :

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.

Martin Pitt (pitti) on 2015-05-02
Changed in systemd (Ubuntu):
status: Confirmed → Triaged
summary: - keyscript option in crypttab ignored
+ keyscript option in crypttab not implemented

@ 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>

Changed in systemd (Ubuntu):
importance: Undecided → Medium
GOo (goo) wrote :

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).

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) wrote :

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

TJ (tj) wrote :

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) wrote :

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."

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.