| 2022-05-23 10:34:42 |
Aaron Rainbolt |
description |
Test hardware is an HP Z220 SFF Workstation, 32 GB RAM, 256 GB SSD + 1 TB SSD, UEFI, no secure boot. Test was done within Gnome Boxes, VM was given SeaBIOS, 4 GB RAM, 20 GB disk space. Host OS is Ubuntu Studio 22.04, guest OS is Lubuntu Kinetic.
If you install Lubuntu with the "Encrypt system" feature offered by Calamares, you will be asked early in the boot process for your security key. The system will not boot without it. When the security key is provided, the early boot screen (with the SeaBIOS text) disappears, and the Plymouth screen appears (well, thanks to Bug #xyz, you have to use a workaround to get it to appear, but whatever). You are then prompted for the security key again, which should be unnecessary.
Steps to reproduce:
1: Boot the latest Lubuntu Kinetic image in Gnome Boxes.
2: Open the Lubuntu installer.
3: At the partitioning step, use "Erase disk", set your swapfile preference to "No swap", check "Encrypt system", and enter a security key (I used "qwe" as my key, if it matters).
4: Plug in your user data and begin the installation.
5: Ensure that "Restart Now" is checked, then click "Done" to reboot into the newly installed OS.
6: Click on the Lubuntu Kinetic VM you just made in Gnome Boxes.
7: Type your passphrase, and press Enter.
Expected result: The system should proceed to finish the boot process and get you to a desktop.
Actual result: You are required to enter the passphrase a second time to finish the boot process.
Notes:
With Arch Linux, this is a known problem, and it appears to have a well-documented workaround here: https://wiki.archlinux.org/title/Dm-crypt/Encrypting_an_entire_system#Avoiding_having_to_enter_the_passphrase_twice I notice that, in the root directory of the encrypted system, there's a "crypto_keyfile.bin" file, which suggests to me that Calamares tried to implement a similar or identical workaround, but failed for some reason.
Also, considering the shortcomings of LUKS1 and the better security offered by LUKS2, I'm wondering if Calamares should be encrypting /boot at all? Why not just put /boot on a separate unencrypted partition, and let Plymouth handle decryption? Granted, this would allow installation of boot-level rootkits on a system without needing to break the encryption, but really, even encrypting /boot doesn't fully prevent that (I can think of at least two attacks that would circumvent an encrypted /boot in the absence of Secure Boot, no matter how good the encryption is), and if the data on the computer is sensitive enough to encrypt, it's probably way more valuable than the computer itself. Why use less effective data protection for the sake of a not-really-awesome bonus, when we could sacrifice the "bonus" in favor of better data protection? Anyway, just my two cents on the topic. |
Test hardware is an HP Z220 SFF Workstation, 32 GB RAM, 256 GB SSD + 1 TB SSD, UEFI, no secure boot. Test was done within Gnome Boxes, VM was given SeaBIOS, 4 GB RAM, 20 GB disk space. Host OS is Ubuntu Studio 22.04, guest OS is Lubuntu Kinetic.
If you install Lubuntu with the "Encrypt system" feature offered by Calamares, you will be asked early in the boot process for your security key. The system will not boot without it. When the security key is provided, the early boot screen (with the SeaBIOS text) disappears, and the Plymouth screen appears (well, due to Bug #1973150, you have to use a workaround to get it to appear, but whatever). You are then prompted for the security key again, which should be unnecessary.
Steps to reproduce:
1: Boot the latest Lubuntu Kinetic image in Gnome Boxes.
2: Open the Lubuntu installer.
3: At the partitioning step, use "Erase disk", set your swapfile preference to "No swap", check "Encrypt system", and enter a security key (I used "qwe" as my key, if it matters).
4: Plug in your user data and begin the installation.
5: Ensure that "Restart Now" is checked, then click "Done" to reboot into the newly installed OS.
6: Click on the Lubuntu Kinetic VM you just made in Gnome Boxes.
7: Type your passphrase, and press Enter.
Expected result: The system should proceed to finish the boot process and get you to a desktop.
Actual result: You are required to enter the passphrase a second time to finish the boot process.
Notes:
With Arch Linux, this is a known problem, and it appears to have a well-documented workaround here: https://wiki.archlinux.org/title/Dm-crypt/Encrypting_an_entire_system#Avoiding_having_to_enter_the_passphrase_twice I notice that, in the root directory of the encrypted system, there's a "crypto_keyfile.bin" file, which suggests to me that Calamares tried to implement a similar or identical workaround, but failed for some reason.
Also, considering the shortcomings of LUKS1 and the better security offered by LUKS2, I'm wondering if Calamares should be encrypting /boot at all? Why not just put /boot on a separate unencrypted partition, and let Plymouth handle decryption? Granted, this would allow installation of boot-level rootkits on a system without needing to break the encryption, but really, even encrypting /boot doesn't fully prevent that (I can think of at least two attacks that would circumvent an encrypted /boot in the absence of Secure Boot, no matter how good the encryption is), and if the data on the computer is sensitive enough to encrypt, it's probably way more valuable than the computer itself. Why use less effective data protection for the sake of a not-really-awesome bonus, when we could sacrifice the "bonus" in favor of better data protection? Anyway, just my two cents on the topic. |
|
