And as I understand it, that is the problem with MOK. In the case of secure boot, the signing key is kept far away in a MS vault. Making it basically impossible

And as I understand it, that is the problem with MOK. In the case of secure boot, the signing key is kept far away in a MS vault. Making it basically impossible to put something in the secure boot chain without actively re-compromising the machine on every reboot. This can be replicated by the end owner, if they replace the MS keys in the secure boot chain as well. But in order to make it as secure, they need the infrastructure to assure that the boot/kernel/etc is all signed on a secure machine somewhere entirely firewalled off from the machines running the signed code. So, AFAIK, shim/MOK, breaks all this. As a root user it then becomes possible to enroll custom keys that allow a 3rd party, or the machine owner (or exploiter) to add code to the boot path nullifying its greatest strength IMHO, which is protecting the boot chain from a root level exploit. At that point the only protection would be a TPM + 3rd party root of trust, that notices the shim measurement of the next stage isn't one that has been reported "safe". Which doesn't exist in linux land, outside of possibly some large corps that have taken ownership of the entire thing for their own internal purposes.