initramfs cryptroot hook script doesn't install cryptsetup if keyfile but no keyscript

Bug #1494851 reported by TJ
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
cryptsetup (Ubuntu)
Fix Released
High
Unassigned
Declined for Wily by Julian Andres Klode
Xenial
New
Undecided
Dimitri John Ledkov
Bionic
New
Undecided
Dimitri John Ledkov

Bug Description

When crypttab specifies a key-file for the container of the root file-system but there is no keyscript= option no cryptsetup support is installed in the initrd.img.

Currently the cryptroot initramfs hook script knows its a problem and will report:

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

This is BAD behaviour that renders the root file-system container inaccessible at boot time.

Regardless of a key-script being available cryptsetup support should be installed into the initrd.img to enable the user to take manual steps to unlock the container. The hook script has no knowledge about pass phrases that might be set in other LUKS slots that are available to the user.

This is the behaviour when a keyscript is specified but doesn't exist.

The attached patch modifies the behaviour to include cryptsetup in the initrd.img and modify the warning to the user.

cryptsetup: WARNING: target LUKS_OS uses a key file, but no keyscript is set. Please ensure there is also a typed pass-phrase set.

Revision history for this message
TJ (tj) wrote :
TJ (tj)
description: updated
Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "Proposed fix" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
TJ (tj)
Changed in cryptsetup (Ubuntu):
importance: Undecided → High
Revision history for this message
TJ (tj) wrote :

Instead of simply warning the user I've developed an alternative approach which does away with the problem entirely.

In this solution I alter the initramfs 'cryptroot' script to support unlock using the keyfile. Currently it will only do that if supported by a keyscript but the two are actually orthogonal.

If a keyscript is specified the keyfile will be available to it via the environment CRYPTTAB_KEY as usual.

The new feature:

If a keyfile is not specified $cryptkey will contain "-" (for /dev/stdin) and 'cryptsetup' will receive the output of the $cryptkeyscript 'askpass' executable's /dev/stdout as usual.

If a keyfile is specified without a keyscript 'cryptroot' will pass it to 'cryptsetup' via --key-file $cryptkey.

Changed in cryptsetup (Ubuntu):
status: In Progress → Confirmed
status: Confirmed → Fix Released
TJ (tj)
Changed in cryptsetup (Ubuntu):
status: Fix Released → Triaged
tags: added: rls-x-incoming
Revision history for this message
Julian Andres Klode (juliank) wrote :

The code does not seem to exist anymore in cosmic and newer, so marking this an incomplete for those as I'm not sure if they are still affected and what happened there precisely.

Anyhow,bionic also seems to be affected looking at a key-file grep.

Changed in cryptsetup (Ubuntu):
status: Triaged → Incomplete
Changed in cryptsetup (Ubuntu):
milestone: ubuntu-15.10 → none
tags: removed: rls-x-incoming
tags: added: rls-ee-incoming
Changed in cryptsetup (Ubuntu Bionic):
assignee: nobody → Dimitri John Ledkov (xnox)
Changed in cryptsetup (Ubuntu Xenial):
assignee: nobody → Dimitri John Ledkov (xnox)
tags: added: id-5ce6beabf9917f722923714d
Revision history for this message
Dimitri John Ledkov (xnox) wrote :

Doesn't affect post-bionic releases. Marking as fixed.

Changed in cryptsetup (Ubuntu):
status: Incomplete → Fix Released
assignee: TJ (tj) → nobody
Steve Langasek (vorlon)
tags: removed: rls-ee-incoming
tags: added: rls-b-notfixing rls-x-notfixing
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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