Bug 462540 - unlocking LUKS encrypted partitions prevents booting if unsuccessful
unlocking LUKS encrypted partitions prevents booting if unsuccessful
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: plymouth (Show other bugs)
rawhide
All Linux
high Severity high
: ---
: ---
Assigned To: Ray Strode [halfline]
Fedora Extras Quality Assurance
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-16 19:33 EDT by James Ralston
Modified: 2013-01-22 18:43 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-15 14:02:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 18079 None None None Never

  None (edit)
Description James Ralston 2008-09-16 19:33:11 EDT
If LUKS encrypted volumes are found during boot, the kernel (or perhaps nash/plymouth) prompts one to enter the passphrase to unlock the partitions.

There MUST be a way to communicate "skip this partition; I don't want to unlock it" to the kernel.

In Fedora 9, hitting Ctrl-D at the "Password:" prompt would cause the partition to be skipped.  Entering a blank/invalid passphrase 3 times in a row would also cause the partition to be skipped.  But neither technique works for the latest Rawhide kernel.

Wanting to boot with only some partitions unlocked is perfectly valid; this ability MUST NOT be denied.

But more critically, the process that searches for LUKS-encrypted partitions is extremely thorough; it detects the LUKS signature on my /dev/sda2 partition:

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1         125     1004031   83  Linux
/dev/sda2             126         375     2008125    0  Empty
/dev/sda3             376       12161    94671045   8e  Linux LVM

While I can appreciate the thoroughness, this is not actually very helpful, because:

$ grep sda2 /etc/crypttab 
swap /dev/sda2 /dev/urandom swap,cipher=aes-cbc-essiv:sha256

Prompting me for a passphrase that I do not (and cannot) know and then refusing to continue to boot unless I enter it: FAIL.  (Somewhat amusing, too, but FAIL nonetheless. ;)

The kernels I've tested are:

0:kernel-2.6.27-0.166.rc0.git8.fc10.x86_64
0:kernel-2.6.27-0.323.rc6.fc10.x86_64

2.6.27-0.166.rc0.git8 doesn't prompt me to unlock /dev/sda2 at all, but 2.6.27-0.323.rc6 exhibits the "I refuse to let you continue booting until we've successfully unlocked all encrypted partitions" bug.
Comment 1 Ray Strode [halfline] 2008-09-16 21:57:52 EDT
So we've talked about adding a 3-try-and-give-up approach.

Really, we should mark what partitions are required for a usable system (/, /home) and what ones are optional (/opt, /srv, etc)

A ctrl-d escape hatch isn't a bad idea, though.
Comment 2 James Ralston 2008-09-18 13:45:06 EDT
I don't think a scheme of marking partitions is going to be tenable.

First, how will you know where the "required" partitions lie?  On my laptop, sda3 is a LUKS-encrypted LVM partition. How would you know the logical volumes that LVM partition contains?  For that matter, what if I had multiple encrypted LVM partitions, and have logical volumes that span them?

Trying to cache that information in /boot (e.g., at system shutdown time) is just asking for stale information.  (E.g., what happens if I make LVM changes, but the system crashes and thus boots with stale cached information?)

Furthermore, I will point out that for some people, the names of the logical volumes themselves might be treated as sensitive information.  If you cache that information in /boot, you may be subverting someone's security profile.

Second, depending on my environment, I might not actually *want* to unlock all encrypted partitions.  E.g., I might have encrypted partitions that use different keys and have different levels of sensitivity.  The boot process can't make the determination of what partitions are appropriate to decrypt at any given time; I have to do it.

I can understand that you want to make the process of unlocking encrypted volumes a user-friendly as possible.  But trying to figure out which partitions are "required" is bound to fail.  You need to trust the user to make that determination at boot time, by unlocking partitions that should be unlocked, and using Ctrl-D (or whatever mechanism) to skip unlocking partitions that shouldn't be unlocked.
Comment 3 Ray Strode [halfline] 2008-09-18 21:22:17 EDT
My point was just that we shouldn't continue boot if continuing boot is going to result in the machine crashing immediately there after.

For instance, we shouldn't continue boot if we can't decrypt / because without / we can't boot.

I think most partitions probably should be optional, so it could be just "/" that is required or maybe "anything in initrd" and possibly "/home"

We can make ctrl-d always continue, though, even for things that are doomed to fail.

Everything else we'll give a 3 tries and give up approach i guess.  Sound good?
Comment 4 James Ralston 2008-09-29 11:37:00 EDT
I think continuing to attempt to find the "/" filesystem isn't unreasonable, but that's going to be tricky, as initrd must re-scan for md devices and LVM volumes (activating any that are found) after every time an encrypted volume is successfully unlocked.

However, this bug is really mkinitrd's fault, not plymouth's. I cracked open my initrd and found this in init:

...
echo Setting up disk encryption: /dev/sda3
plymouth ask-for-password --command "cryptsetup luksOpen /dev/sda3 luks-sda3"
echo Setting up disk encryption: /dev/sda2
plymouth ask-for-password --command "cryptsetup luksOpen /dev/sda2 swap"
...

But:

$ grep /dev/sda2 /etc/crypttab 
swap       /dev/sda2  /dev/urandom  swap,cipher=aes-cbc-essiv:sha256

In other words, mkinitrd did the wrong thing; it never should have added the lines invoking plymouth to unlock /dev/sda2, because it's glaringly obvious from /etc/crypttab that no one will have a key to unlock it.

Should I open another bug against mkinitrd, or do you want to reassign this one?
Comment 5 James Ralston 2008-09-29 11:38:09 EDT
Also, I have no issues with the "try 3 times and give up; Ctrl-D always continues" approach; that seems perfectly reasonable.
Comment 6 Ray Strode [halfline] 2008-09-29 13:13:48 EDT
separate bug please.  I'll use this bug for tracking the 3-tries and give up / ctrl-d issue.
Comment 7 Ray Strode [halfline] 2008-10-15 13:58:23 EDT
So the 3-tries-and-bail bits landed a while ago.

I haven't done the ctrl-d bits, yet.

I'd like to track that upstream, since it's not crucial to get done for F10 initial release and we're coming down to the wire now.
Comment 8 James Ralston 2008-10-20 14:10:12 EDT
I think it's reasonable to track the Ctrl-D bits upstream, yes.

(I didn't file a bug against mkinitrd, because someone already noticed and fixed it.)

Note You need to log in before you can comment on or make changes to this bug.