Indeed, though it won't give them root persistence but yes. It's a bit harder to weed out when it's hidden somewhere in the OS but it's not a serious protection IMO, even if file signatures are validated on every boot like Apple does.
But they also use this to enforce DRM, for example if you turn off system integrity protection you can't run iOS apps anymore. This is exactly the kind of thing that bothers me about it.
> Indeed, though it won't give them root persistence but yes.
If you gain root by editing .bashrc and replacing sudo or placing a file in .local/share/applications to replace an application that the user trusts (like the Settings app) to give their password to, then you can just inject your payload into the initramfs and get persistence.
I don't believe any desktop distro is signing and verifying the initramfs.
> Apple does sign the entire boot process but they have the benefit of a strictly defined hardware set to support
Windows can also sign the entire boot process, but they unlike Apple can't make the system folders read-only due to backwards compatability (Windows 10S experimented with this idea but was scrapped).
There's nothing stopping Linux distros from having a secure boot process, but the initramfs either has to be scrapped or pre-built by the distro.
>And yeah the problem is that the initramfs is built on the machine itself. So it would have to have the signing keys which defeats the purpose.
Just brainstorming here.
What if the initramfs was rebuilt every time the OS was upgraded. During an OS upgrade, the user is asked to cold boot, the machine does a special boot, requests the user's disk decryption password, and uses it to build and sign the new initramfs, based on files signed by distro maintainers.
Then for every ordinary boot, immediately after disk decryption, we keep the disk decryption password in memory for just a little bit longer, and use it to check the signature on the initramfs before continuing with the boot.
The "signature" could be the secure hash of [the disk decryption password concatenated with the initramfs binary], or something (ask a crypto expert -- perhaps KDF+HMAC is better?)
I'm guessing the disk decryption password is much harder to steal than the user's root password?
(I might be totally out to lunch here, I know nothing about Linux boot. The above comment is written in the spirit of "learning about things by asking dumb questions"!)
* What if the initramfs was rebuilt every time the OS was upgraded.*
On most distributions, they already are if the kernel changes in anyway. This is what ends up filling up your /boot partition.
Then for every ordinary boot, immediately after disk decryption, we keep the disk decryption password in memory for just a little bit longer, and use it to check the signature on the initramfs before continuing with the boot.
You can just reuse the existing architecture of secure boot/tpm to store public keys (although GRUB is a disaster and will likely break your boot chain of trust). You normally can't add additional keys unless the system is in setup mode. But, the process to add a self signed key is not user friendly and you'd still need to store the private key on disk to sign additional images, which malware can access.
There is a process to generate something known as a UKI, where it can be a signed kernel/initramfs verified by the firmware secure boot, but I believe only Red Hat has keys to sign anything and most distos get given a signed shim that will only boot the turd called GRUB.
Yep. An attacker can just surreptitiously add a line to your .bashrc instead of modifying the base OS.