There are improvements that could improve out of the box security for most linux distros.
default to encrypted root install, user has to disable
support encrypted boot via multiple methods, e.g. FDE, double prompt, etc
make secure boot easier to understand and manage
support smartcard and tpm setup during install
make smartcard and tpm use easier to understand and manage after install
Regardless of what the rest of the users and linux distros are doing, what can I practically do to increase security for myself.
Disable USB Boot
Set Admin password on Firmware
Use Secure Boot
Attempt Full Disk Encryption, if that fails at least encrypt root drive
Use very strong passwords
Use tpm and smartcards instead of passwords for login and admin work
keep strong passwords as backup for access
use tpm and smartcard for encrypted root unlock
The Ubuntu Full Disk Encryption uses secure boot with signed Unified Kernel Images. It would be great if I could get my own signed images working.
Since the hardware in the computer has to get access to the data on the hard drives to boot into an operating system chosen and installed by the end user it is challenging to protect every thing with encryption. While the use of some specialized hardware makes this viable it requires complicated and risky setup. The general model has been to leave the boot partition decrypted so that the standard UEFI boot processes may access it. Anotther option is to encrypt boot with luks1 at which two password prompts are presented. 1) decrypt boot 2) decrypt root.
If we use the tpm to protect one of them we may be able to cut out one of the passwords. What if we tpm protect boot and then we use a smartcard to decrypt root?
Ubuntu 26.10 has implemented Full Disk Encryption which uses the tpm to unlock the entire disk but this only works with ubuntu provided kernels and initrd. This precludes anyone from making customization such as adding smartcard support to the boot process when it is not present out of the box.
If the boot partition and the EFI partition are unencrypted an attacker may modify them by gaining physical access. The goal of secure boot is to protect the user by having the hardware make extra security checks before booting up.
This is a great idea but gets really complicated and difficult to understand for non technical end users. (I'm a very technical end user and I still don't understand the relationship between MOKs and shims and everything else).
In addition, this model has a few major gaps which render it not secure.
initrd is not signed or checked. since the initrd is customized during the update of packages (multiple and many) it cannot be signed by the vendors (Microsoft, Ubuntu, Redhat, etc.)
Booting of encrypted drives is challenging and often not possible leaving the initrd open to modification.
Ideally, all data on the system would be protected from modification by an attacker. If the boot partition were encrypted it would ensure this but only if an attacker with physical access does not have access to the decryption keys. Since the boot process has to have access to decrypt it is challenging to achieve both.
Grub supports some encrypted booting features. It might make sense to expand this but if the attacker has access to the EFI partition the boot process may still be modified. This approach might have to be paired with something like secure boot to be effective.
When TPM was introduced there was great concern that Microsoft would leverage it to prevent install of non MS systems on PCs and servers. The mitigation for this concern has mostly been to turn off the security features on windows pcs and ignore TPM during Linux installs. It is good to see that we are finally (after 20 years) starting to work with the technology though we still have challenges.
Given that a lot of computers (maybe all now) have TPM modules the Linux community should offer users the use of it during install and some distributions are starting to do this.
Ubuntu is using the TMP for boot unlocking starting in 26.10 but it has limitations. It may be manually configured in various configurations. The latest installer for fedora may support tpm but I didn't notice it during install. In any case fedora supports tpm unlock of encrypted luks partitions after install.
Those of us without working tpms and full disk encryption do not have is full security. Even with Secure Boot we have a huge hole in that the initrd is not signed or checked. The heads project addresses this but it is not an option for 99% of the computers in the world. Can we extend the chain of trust from Secure boot of the kernel to the initrd? Can the tpm or other hardware assist with this?
For Booting Linux Secure boot looks at signatures for shims used by linux vendors. linux vendors boot whatever kernels they want with the shims. But the initrd is not checked and initrd gets updated with many package installs.
Are the kernels signed? yes
How can we protect the initrd which cannot be signed by the vendor?
User has to sign
kernel has to have a way to securely check the signature
fallback and warnings not available. must boot a different kernel
The best approach seems to be to use Unified Kernel Images (UKI) where the initrd is combined with the kernel and protected by tpm hashing, etc. I tried this before and ran into problems but will continue working with it.
When UKI is not an option is it possible to extend the kernel chain of trust to the intird? why do we have all of this machine owner key infrastructure that is hard to understand and setup if it doesn't actually protect the full system?
The evil maid attack is when someone gets physical access to the system to make modifications such as the boot process. How could we protect against it?
move boot files to removable usb
move entire system to removable usb
full disk encryption
it is almost impossible to keep a usb stick protected at all times. (in the shower?) but it would reduce the attack vector.