In most of my installations I usually create 4 partitions (i.e. /boot, /boot/efi, /, and /home )using the advanced tool. While I can encrypt the /, and /home directories the partitioner disallows encrypting /boot and /boot/efi directories. I understand why /boot/efi can not be encrypted but /boot can be encrypted in other installers like yast and calamaries. Why does anaconda not allow doing so.
2 Likes
I guess only two people are interested in this question.
I would image it would depend on where the decryption is done. If it is done by the code/files under /boot/efi, then /boot/efi cannot be encrypted. Likewise, if it is done in the initramfs stage, then /boot cannot be encrypted (because it contains initrd). I thought a lot of the LUKS code was run from the initramfs stage. But I don’t know for sure. I don’t use it.
1 Like
I don’t understand what the purpose is of encrypting /boot.
As far as I know GRUB2 is able to unlock LUKS devices with its cryptomount command, which therefore enables encryption of the /boot partition. Some features like such as splash screens or remote unlocking may be incompatable but shouldn’t the user be able to choose. Opensuse for example first asks the passphrase for /boot in command line mode if the user chose to encrypt the /bootpartition and then keeps running the initramfs code after that it prompts for the password for the other partitions with the splash screen and all.
1 Like
3 Likes
To reduce the amount of data held in plaintext (linux kernel and the initial ramdisk) and may be reduce the surface for evil maid type of attacks by a little bit. I know there are better options for that but I am curious as to why it is not possible only in fedora while other distros are able to provide through yast and calamaries.
Good to know there is a discussion about it in the dev mailing list.
FYI, if the goal is just to keep the number of unencrypted partitions to a minimum, there is another way to do it. It is possible to mount the entire EFI partition to /boot such that the EFI partition will contain the bootloader and the kernel and initramfs. This method works especially well with other bootloaders like systemd-boot and syslinux. I haven’t configured encryption with such a layout, but it has been reported to work:
https://discussion.fedoraproject.org/t/dual-booting-windows-10-and-fedora-34/62879/11
Wouldn’t doing so still leave us with unencrypted kernel and initramfs which are the parts I was hopping to avoid leaving in plain text.
To be honest I am interested in the technical limitations that are preventing the installer from encrypting /boot and if I could solve it in my custom images which use anaconda as an installer.
Yes, but it is possible to guarantee their integrity by signing them rather than encrypting the partition.
I’m sure there is a way since it is all open source. I’m not that familiar with Anaconda though.
Thanks @gbl. Signing them might be better and I do something similar with modern gear. I was hoping to keep it an all software solution since I move hard-disks frequently (i.e. because I use crappy, old, used hardware since that is what we have here in Ethiopia) and some of that gear might not properly support UEFI, TPM or things like that. I can also drop down to the command line and do it manually (which I do frequently) but I was wondering about why the installer does not allow doing so and if there is a way to simplify things. Like I said other installers allow doing so.
There is now an excellent guide on how to do this on F37. Encrypt /boot on F37