Dual System Secure Boot (Gentoo+Windows), shim vs non shim

[nxe9]

Hi, I am considering secure boot on a dual system (gentoo + win11). I have read few articles and I want to make sure I understand the difference between shim and non shim secure boot in terms of security specifically with reference to one example.

Let’s assume we have a malware on our system which interfered with our boot binary. Let's assume that our private keys are well secured and the malicious actor has no access to them. In the case of non shim, for the system to boot the malware would have to modify the uefi db data. In turn, to do this, you would need a private key PK/KEK (which is not available) or resetting the PK (setup mode) and uploading your own, which would require running UEFI, i.e. physical access to the computer. In this case, the malware would not harm us regarding the boot process.

In the case of shim, the MOK list is modified. Since the MOK list is not stored in UEFI memory, malware could modify not only our boot binary, but also the MOK list without having physical access to the computer, which would make it possible to start the system with replaced boot components. As a result, the safety associated with shim is lower than non shim.

So what are the benefits of shim? From what I understand, there is no need to backup old, delete old and generate new keys and create a compound (old+new) because the shim is signed with a Microsoft certificate. However, we do this at the expense of security, because we transfer some public keys to the operating system level.

Is everything I wrote correct?

[GDH-gentoo]

[nxe9]

OK, but there is still, in my opinion, a key difference. The MOK list can be reset and overwritten from the system level without knowing the private key. According to https://wiki.gentoo.org/wiki/Shim

[GDH-gentoo]

It is mentioned in only one sentence in that Wiki article, but the MokManager does a password verification for that step. There is a procedure for setting up the password for importing a new MOK that I don't see described in the article.
_________________

[sMueggli]

Secure Boot is based on a chain of trust. The root of this trust is the PK (platform key). The PK is usually set by the OEM or mainboard vendor. Where this chain of trust ends depends on the distribution. Normally the chain of trust ends with the signed kernel modules (but might end with shim).

The next step is the KEK (key exchange keys). The KEKs are signed with the PK.
At least one of the KEK is a Microsoft public key which is used to verify the signature of the Microsoft UEFI binaries and also to verify the signature of shim. Usually shim loads then Grub and is normally checking whether Grub is signed with a distribution specific key.

PK and KEK are public keys or certificates (not sure, but I guess they are certificates, not just public keys). They do not contain any private or secret stuff. Then there are at least two lists: db and dbx. The list of known certificates and the list of forbidden certificates (comparable with a CRL in a PKI).

You can replace every bit of this chain of trust, without knowing the private key. But usually this is only possible with physical access to the system. If the MOK list is part of the chain of trust, then the list must be signed with one of the "trustworthy" keys.

In an ideal world, the private keys are not stored (and were not created) on the system that is protected by Secure Boot.

[nxe9]

@GDH-gentoo: In my opinion, this does not change anything, because in fact, to add the signed modules to the MOK list I need to have a private key, but I can clear such MOK list from the system level (just as I can clear the PK and the entire trust chain from the UEFI level). Unless I'm still not understanding something.

@sMueggli: I more or less understand it the way you wrote it. What I meant was that in the case of a shim digitally signed by Microsoft I have two chains of trust. The first one from PK to shim, and the second one after shim. In my opinion, such a chain of trust is easier to break and can be broken from the operating system level. In the case of one continuous chain from PK to kernel modules I am not able to do this. I'm leaving out the issue of physical access, because then you can actually manipulate everything, but that's a different topic. Besides, you wrote about it yourself - "You can replace every bit of this chain of trust, without knowing the private key. But usually this is only possible with physical access to the system.".

[pietinger]

[nxe9]

@pietinger: I'm not sure I understand you correctly.

[peteblank]

it used to be that bootkits and router malware were rare but apparently now theyre being sold
https://thecyberexpress.com/blacklotus-uefi-bootkit-hacking-forums/amp/
if you ask me i dont like uefi it should have stayed as bios, the bliat that uefi brought made the attack surface wider. it used to be eeprom now its flash so it can be rewritten multiple times without flashibg it with electricity.
imagine if you combine a router malware that hops from device to device with a bootkit and whatever else.
you could be visiting a porn site and ad has malware that can bypass the browsers sandbox and just like that.
i feel better with secure boot but id also feel better getting past the gentoo terminal heh. it can wait.

[pietinger]

[sMueggli]

[sMueggli]

[nxe9]

[sMueggli]

The Fedora way (I might be wrong): Fedora is a Linux distribution and is signing kernel, modules, Grub and probably other stuff with a Fedora-specific (private) key. Then Fedora embeds the public Fedora-specific key in shim. Then Fedora makes a request at Microsoft to sign the (reproducible) build of the Fedora-specific shim. People at Microsoft are analysing the code and probably the process behind (weaknesses in the process, identity [is the requester really part of Fedora and is the requester in the possession of the private key?]) and will sign the Fedora-specific shim binary (or not).

The end user has a PC with a PK (not in possess of the private key) and some KEKs. At least one of the KEK is from Microsoft. Every KEK is signed by the PK. Again, the end user (normally) does not have any private key for the KEKs. But the user does not need to be in possess of any of those private keys.

From https://github.com/rhboot/shim:

[pietinger]

I was never a fan of shim ... and in retrospect that was justified:
https://eclypsium.com/blog/the-real-shim-shady-how-cve-2023-40547-impacts-most-linux-systems/

I have the advantage that I do not dual-boot with windows and can therefore use my own keys:
https://forums.gentoo.org/viewtopic-p-8492354.html#8492354
_________________
https://wiki.gentoo.org/wiki/User:Pietinger

[nxe9]

@sMueggli:
Thank you very much. Your description was at a level of abstraction where I could follow. Most of your description made sense to me and that's how I understood most of the issue so far. However, I still had trouble understanding the idea of ​​the MOK list, because in my opinion, introducing it means that an attacker could bypass the whole idea of ​​secure boot from the user space. However, I found the answer on the oracle website, which for me is the missing puzzle in this whole thread.

[nxe9]

I managed to secure boot via shim without bootloader and without touching the firmware with signed UKI. I want to share my knowledge for those who might have problems because not everything is very well documented. I have two systems, one is Gentoo and the other is Windows 11 and it works without any problems as secure boot.

The boot process looks like this in my case