If there is anyone who is interested in the research of the invisiblethingslab.com, confidential computing, and firmware security, please reply with information about how to implement attestation and kernel and firmware lockdowns in Fedora.
I am interested in protecting a system from cold boot attacks, thunderbolt and evil maid attacks, and ensuring that there is a solid hardware to kernel chain of trust.
Fedora 37 and 38 have a GUI indicator of hardware security that can be accessed through
Settings → Privacy → Device Security → “checks failed,” “secure boot,” and “security events”
How should sysadmins address alerts in this section?
The information provided by fwupd (FwupdPlugin – 1.0) does not specify exactly how to pass “fails” in Fedora. For example,
1 ) How do I enable Secure Boot when Coreboot doesn’t have the usual BIOS interface? (HSI-1)
2 ) How do I lock the Firmware BIOS Region? (HSI-1)
3 ) Firmware Write Protection (HSI-1)
4 ) Intel BootGuard Fuse, Verified Boot, ACM, Error Policy (HSI-2)
5 ) How to encrypt RAM (HSI-4)
6 ) Linux Kernel Lockdown and Verification (HSI-4)
Also, has anyone used Yubikey, dongles, or other methods to protect devices from physical access attacks?
Does FwupdPlugin – 1.0: Host Security ID Specification help? Using “fwupdmgr security” on the command line can fix some things, and we’re working on fixing a lot more. Also be aware that unless you’re provisioning BootGuard having Coreboot doesn’t magically give you a free pass.
I think the strategy varies depending on whether a system is utilizing Coreboot or hardening the hardware-software “mortar” with proprietary signing. That’s the distinction you are alluding to when you mention a free pass, right? You must side with proprietary signing (or, in other words, the way you would phrase that approach).
Let me elaborate. What do you think about the implications of Vault 7, for instance, and the approach taken by Purism? See Coreboot Firmware on Purism Librem Devices – Purism
MEI is considered by some to be a security risk.
My SWAP is encrypted, but if BootGuard and SecureBoot are not passed, then it doesn’t matter if SWAP is encrypted if the device is stolen? That’s the meaning of the Cold Boot attack, right? HSI-4 systems would be secure from physical access attacks.
How important is it for SPI to be locked?
Is a kernel considered tainted if the copr is not “validated” or “approved” by a more official authority? A COPR (syzdell for s76 computers) is ECM and firmware, so that should not effect a kernel. How do kernels get tainted? I have a notice saying that the kernel was tainted, untainted, and retainted before being untainted.
Provisioning is generating device-unique secrets like self-signed certificates, right? And that requires expertise. Would you say that such knowledge is reasonably obtainable through self-study?
As for the Security ID Specification, the output is: HSI:INVALID:missing-data. But I think that is just because MEI has been neutralized in Coreboot.
It depends if you want to be able to write the SPI from root. From my point of view this is bad, as any rootkit turns into persistent rootkit, which can survive a re-image.
