Confirm root remains safely encrypted

English Install/Boot/Login
1

Hi all,

Linux newbie and recent Tumbleweed adopter. Please feel free to assume a minimum level of knowledge and/or experience. I welcome corrections and pointers, but may struggle with jargon-dense documentation.

During my installation, I created a single LVM-managed LUKS encrypted root volume, and found myself entering two passwords: once during boot (cannot recall at precisely which stage of the process, and I did not take photos), and then another post-boot for the actual desktop environment login screen. I initially followed the guidance outlined within SDB:Encrypted root file system, which had no effect. After re-reading the above (and some forum posts, which I also unfortunately did not retain links to), I came to the conclusion that this was perhaps normal, and that I had been experiencing the standard/minimum possible number of logins to begin with.

However, I recently had to rebuild the initrd for an unrelated reason (sudo dracut -f), after which point I was only asked for one password, specifically for the desktop environment login only. There is no longer any password prompt during the booting process itself.

Should I be concerned about this, i.e. did I end up including the decryption key in an area of my disk that leaves my root vulnerable to decryption by anyone with physical access to the device?[1]

Commands entered to add root key file the first time around:

sudo touch /.nvme0n1p2.key
sudo chmod 600 /.nvme0n1p2.key
sudo dd if=/dev/urandom of=/.nvme0n1p2.key bs=1024 count=1
sudo cryptsetup luksAddKey /dev/nvme0n1p2 /.nvme0n1p2.key
sudo nano /etc/crypttab
echo -e 'install_items+=" /.nvme0n1p2.key "' | sudo tee --append /etc/dracut.conf.d/99-root-key.conf > /dev/null
sudo dracut -f

Current contents of /etc/crypttab:

cr_nvme-eui.01000000000000008ce38e040126dddc-part2 UUID=c5916411-34d4-4979-aaf3-f44100fe7fef /.nvme0n1p2.key x-initrd.attach,tpm2-device=auto,tpm2-measure-pcr=yes

Output of lsblk:

NAME                                                   MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
nvme0n1                                                259:0    0 953.9G  0 disk  
├─nvme0n1p1                                            259:1    0     1G  0 part  /boot/efi
└─nvme0n1p2                                            259:2    0 952.9G  0 part  
  └─cr_nvme-eui.01000000000000008ce38e040126dddc-part2 254:0    0 952.9G  0 crypt 
    ├─system-root                                      254:1    0 937.5G  0 lvm   /var
    │                                                                             /usr/local
    │                                                                             /srv
    │                                                                             /root
    │                                                                             /home
    │                                                                             /opt
    │                                                                             /.snapshots
    │                                                                             /
    └─system-swap                                      254:2    0  15.4G  0 lvm   [SWAP]

Thank you in advance for your insights/help!

  1. For context, I did read and note the aside on SDB:Encrypted root file system about only following the root key file procedure if /boot is also encrypted, but it was unclear to me whether this requirement held for /boot/efi. ↩︎

2

I don’t know if that’s due to TPM magic or something being genuinely broken, I don’t use TPM auto-unlock as it’s little better than leaving everything unencrypted. :open_book:

Whatever the case, the result appears to be same. :skull:

3

Thank you @pavinjoseph! That is pretty much what I feared.

The issue is that I never tried to set up TPM auto-unlock, and only followed the process set out in SDB:Encrypted root file system Section 4.1.1 Automatically decrypt the root partition in Leap and Tumbleweed. My understanding was that this passwordless behaviour should not have resulted from following the steps outlined (and, indeed, did not at first).

How would I reverse this? Is it just a matter of undoing all the steps in 4.1.1? Or is something else causing this?

EDIT: Specifically for step 5 in 4.1.1, to undo echo -e 'install_items+=" /.nvme0n1p2.key "' | sudo tee --append /etc/dracut.conf.d/99-root-key.conf > /dev/null, would I need to delete 99-root-key.conf entirely, or can I just edit it with nano to be blank? I think I can undo all the other instructions without further help.

4

Looks like leap-16-not-asking-for-encryption-key ; I’m no expert, so cannot say if it is less safe.

2 Likes
5

That’s for unlocking the root FS after supplying password to the grub bootloader.
But what could cause the bootloader to not ask for password? :thinking:
I use grub2, are your using the fancy new grub2-bls or sd-boot?

This would imply TPM shenanigans! :face_exhaling:

6

Which commands would I run to check whether I use grub2-bls/sd-boot?

Those tmp2 lines were already in /etc/crypttab, and were not added by me. :worried:

7

You most probably are using either of those since this is a new install and TPM was auto-configured. :face_with_monocle:

You can check if it’s installed:

zypper se -si '/sdbootutil$|grub2.*bls/'
8

My guess is different and maybe wrong but here it is. As far as I can see there should be no need for the key you’ve created unless I’m missing something.

With multiple partitions, every partition that has to be decrypted will require you to enter the password.

You shouldn’t need the key you’ve set up for root. Grub (if you’re using it) should only require the passphrase once on boot and then pass it on. Grub did have an issue before not passing it on but that has been resolved.

The key you’ve created is doing what it’s supposed to though and hence you aren’t being prompted for a password to decrypt the root partition at any stage.

So currently you probably aren’t deriving any benefit from having an encrypted partition because it’s being automatically unlocked. You might conceivably have been prompted twice for another encrypted partition that was being mounted in the boot process.

Now that you’ve run dracut -f you could possibly try renaming the key you’ve created or reversing the changes you made to ‘/etc/dracut.conf.d/99-root-key.conf’ and see what behaviour you get when rebooting.

9

This guide has info on un-enrolling a TPM key:

Make absolutely sure you know the LUKS password, backup your data, then:

  • unenroll TPM key
  • reboot!

With your current config, the bootloader should ask for the LUKS encryption password. Once it’s supplied the bootloader will open with its menu depending on your config and boot the system without asking for root/swap FS password.

1 Like
10

Yea, I think you need to edit 99-root-key.conf and then run dracut -f again. Then reboot. If you’re still needing to enter the password twice it’s probably another partition that is causing the double prompt.

11

This is the output of zypper se -si '/sdbootutil$|grub2.*bls/':

S  | Name       | Type    | Version                   | Arch   | Repository
---+------------+---------+---------------------------+--------+-----------
i+ | sdbootutil | package | 1+git20260813.357956d-1.1 | x86_64 | repo-oss

So guessing that’s a “yes” to sd-boot?

1 Like
12

you don’t need the line you have in crypttab

cr_nvme-eui.01000000000000008ce38e040126dddc-part2 UUID=c5916411-34d4-4979-aaf3-f44100fe7fef /.nvme0n1p2.key x-initrd.attach,tpm2-device=auto,tpm2-measure-pcr=yes

That’s what is causing the partition to automatically decrypt is my guess. All partitions are encrypted but no crypttab entry for root on my system.

13

/etc/dracut.conf.d/99-root-key.conf now entirely blank, rebuilt initrd with dracut -f, and rebooted, but no luck, unfortunately! Still no password. :confused:

Thank you, though! This was worth trying.

14

The only thing I changed in that line was add the path to the root key file; the rest was autogenerated on install.

Perhaps I should remove the root key file path and replace it with “none”, as it was originally (then rebuild initrd again)?

15

Yea, and make sure to remove crypttab entry. if that doesn’t work then I’m probably on the wrong track.

16

Sorry yes, revert line in crypttab to none or whatever it was before. Not what I said, I have no idea about the tpm stuff.

1 Like
17

Thank you @FrankyU2!!! Going to mark this comment with the full narrative of my actions as the “Solution”; let me know if that’s an issue!

I did the following:

  • Removed all text added to /etc/dracut.conf.d/99-root-key.conf.
  • Unenrolled the extra root key file with sudo cryptsetup luksRemoveKey /dev/nvme0n1p2 /.nvme0n1p2.key.
  • Removed the file path to the root key file from /etc/crypttab, and reverted that column’s entry to none.
  • Rebuilt initrd with dracut -f --regenerate-all.
  • Rebooted.

I was prompted for the root volume password immediately after the bootloader screen, which I’m going to hope was the correct behaviour. The rest of the boot was as expected/uneventful.

Still not clear why:

  • This behaviour didn’t manifest immediately after I added/enrolled/registered the root key file, even though I also ran dracut -f that first time.
  • What the optimal login/prompt behaviour for encrypted root volumes is, i.e. whether what is happening to me now is adequate from a safety perspective. Would appreciate it if readers chipped in with what their set-up does/what they would consider to be “normal”.
18

Thank you @pavinjoseph! This was next on my list of potential solutions, but the boot password has returned now, so didn’t need to try it in the end!

Possible this will be an issue for others in the future, in which case helpful to have the resource in the same thread.

19

Glad it’s behaving normally now from my perspective. This is how my system behaves at any rate. Not really sure why grub was prompting twice before though :thinking:

20

@FrankyU2 OP is using sdboot, not grub like on older installations. :no_entry:
It has been a while since I did an install, not sure if grub is still an option or Agama is polite enough to ask for such things from the user. :face_exhaling:

@TooManyCucumbers I wouldn’t consider this solved! It has been a recurring issue of many years with openSUSE that the LUKS unlock key is not passed from the bootloader to the root FS. The bootloader, initrd, etc. lives on /boot which is encrypted - only the EFI stub lives on the unencrypted /boot/efi. :face_with_monocle:

Right now, the bootloader (and consequently your LUKS container) is being auto unlocked by TPM :magic_wand:. The decryption key is in memory, it’s just not being passed to the root FS due to the bug - hence it asking you for the LUKS password now that you’ve reverted the changes from the wiki. :warning:

To solve this, you’d need to disable TPM unlock and make sure the bootloader stub asks for the LUKS password before you’re even able to see the bootloader proper and its menu - that’s a secure system. You can then proceed to follow the wiki and put the unlock key in the encrypted initrd image for root/swap FS keyfile based auto unlock. :closed_lock_with_key:

1 Like