Bug 1594217
| Summary: | luksmeta slots come back from the dead when formatting a LUKS device | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Marius Vollmer <mvollmer> |
| Component: | cryptsetup | Assignee: | Milan Broz <gmazyland> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 28 | CC: | agk, gmazyland, npmccallum, okozina |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | cryptsetup-2.0.5-1.fc28 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-11-17 05:22:20 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Marius Vollmer
2018-06-22 12:05:48 UTC
LUKS never touches the header gap. Use: luksmeta nuke -d /dev/sdb. > LUKS never touches the header gap. Use: luksmeta nuke -d /dev/sdb. Wouldn't it be nice if cryptsetup itself would wipe its gap? I'll reassign to find out. I have also filed https://github.com/storaged-project/libblockdev/issues/391. I'm inclining to close it again, but few thoughts: LUKS1 header size (including keyslots areas) depends on volume key size used during format action. If you change key size the respective luksmeta offset may change as well. IOW, even if add such wipe it will not work in all cases. Nathaniel is right, luksmeta nuke is the correct way forward here. Something like: a) cryptsetup isLuks --type luks1 /dev/sdb ? b) luksmeta nuke -d /dev/sdb c) cryptsetup luksFormat... But we already check for luksmeta presence if user wants to do up-conversion to LUKSv2 format. (In reply to Ondrej Kozina from comment #3) > Something like: > a) cryptsetup isLuks --type luks1 /dev/sdb ? > b) luksmeta nuke -d /dev/sdb > c) cryptsetup luksFormat... Why not the following sequence? a) cryptsetup luksFormat --type luks1 /dev/sdb b) luksmeta nuke -d /dev/sdb Step b) could actually also be "luksmeta init", no? What else would people do with the gap anyway? Here is a scenario that shows the potential harm of this bug:
# dd if=/dev/zero of=/dev/sdb
# cryptsetup luksFormat /dev/sdb
# clevis luks bind -d /dev/sdb tang '{ "url": "http://192.168.100.1:88" }'
# cryptsetup luksFormat /dev/sdb
# cryptsetup luksAddKey /dev/sdb
# clevis luks bind -d /dev/sdb tang '{ "url": "http://192.168.100.1:88" }'
# luksmeta show -d /dev/sdb
0 active empty
1 active cb6e8904-81ff-40da-a84a-07ab9ab5715e
2 active cb6e8904-81ff-40da-a84a-07ab9ab5715e
Clevis is now broken for /dev/sdb because the passphrase in slot 1 does not match the result of decryption with the tang pin anymore.
# clevis luks unlock -d /dev/sdb
No key available with this passphrase.
If /dev/sdb should be unlocked during boot, the next boot will time out and end up in the rescue shell.
I will lobby for a fix in libblockdev.
(In reply to Marius Vollmer from comment #5) > I will lobby for a fix in libblockdev. They don't want it either. I can put a workaround in Cockpit, but that is arguably the worst place. Please advise. (In reply to Marius Vollmer from comment #5) > Here is a scenario that shows the potential harm of this bug: > > # dd if=/dev/zero of=/dev/sdb > # cryptsetup luksFormat /dev/sdb > # clevis luks bind -d /dev/sdb tang '{ "url": "http://192.168.100.1:88" }' > > # cryptsetup luksFormat /dev/sdb > # cryptsetup luksAddKey /dev/sdb > # clevis luks bind -d /dev/sdb tang '{ "url": "http://192.168.100.1:88" }' > # luksmeta show -d /dev/sdb > 0 active empty > 1 active cb6e8904-81ff-40da-a84a-07ab9ab5715e > 2 active cb6e8904-81ff-40da-a84a-07ab9ab5715e > > Clevis is now broken for /dev/sdb because the passphrase in slot 1 does not > match the result of decryption with the tang pin anymore. And it would also break if user reencrypted the device, or performed LUKS header restore from backup where there is no 'nbde' keyslot. My point is that even if we fix this very case there will always be another one. 'bind' should probably check if the keyslot can be unlocked before it finishes the bind operation. It's a simple 'test passphrase for a keyslot' case from cryptsetup/luks perspective. (In reply to Ondrej Kozina from comment #7) > And it would also break if user reencrypted the device, or performed LUKS > header restore from backup where there is no 'nbde' keyslot. My point is > that even if we fix this very case there will always be another one. Always? Isn't the list of cases finite? Anyway, y'all know about the problem and I let you go ahead and do the right thing. The right thing is to move to LUKSv2 where luksmeta isn't needed. It was always a stop-gap. It gets mostly fixed by following upstream commit: https://gitlab.com/cryptsetup/cryptsetup/commit/c2bce3e93ecee41f661b589ee28f112eb538259e It'll not guarantee cryptstup erase luksmeta metadata in every case (see comment #3) but it fixes the problem you see after formating fresh LUKS device. cryptsetup-2.0.5-1.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-8936092f99 cryptsetup-2.0.5-1.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-8936092f99 cryptsetup-2.0.5-1.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report. |