Comment by NekkoDroid 4 days ago
AFAIU (I haven't looked much into it) shim basically exists so that MS signs the shim once (or only a few times when updated), which has the distro public key embedded, which does further verification of the chain (bootloader/kernel) which gets updated more frequently.
> An adversary can simply boot their own own copy of shim with whatever OS they like.
They'd need to get MS to sign it first, but otherwise yea. That's why I remove the MS keys on my non-windows systems.
I don't know all the ins and outs, but because of the Machine Owner Key (MOK) mechanism in shim, it should be possible to boot arbitrary OSes without MS signing anything.
Your step of removing the MS keys works of course :) Although I've heard that can be risky on various systems that need to load MS-signed EEPROMS. Also I think that firmware updates can be problematic?
> Although I've heard that can be risky on various systems that need to load MS-signed EEPROMS
Yea, I bricked a Gigabyte board and still haven't been able to fix it. I just replaced it with an Asrock board and that has settings for what to do with option-rom when secureboot is enabled (always execute, always deny, allow execute, defer execute, deny execute and query user) and I have no clue what half of them specifically do (like, does "allow execute" only execute if a matching key exists and doesn't execute if it doesn't? and what is the difference between "always deny" and "deny execute"? and defer to when??). But I just set it to always execute and my problem is solved.
That's basically my understanding too. But since you can still boot any shim-supported distro, Secure Boot + shim practically gains you nothing. An adversary can simply boot their own own copy of shim with whatever OS they like.