Security.framework exports functions like SecCodeCheckValidityWithErrors() ref, src that are used to verify correctness of code signatures against the certificate store.
However, who inspects the inspector? Security.framework is signed as well. How can kernel verify it's signature without loading Security.framework beforehand to get access to those functions? And wouldn't that mean that just replacing Security.framework with custom implementation that blindly accepts any signature is just enough to effectively shut down all the code signing protection?
If kernel has static version of Security.framework compiled in, then what's the point of having it as a separate framework? If it does not, does it just blindly trust this particular framework to be untampered?
Background: I had recently replaced a builtin keyboard on my Macbook, and it announces itself with wrong USB PID, so it's recognized as JIS instead of ANSI. It can be fixed by changing a single line in AppleUSBTCKeyboard.kext's Info.plist, but this invalidates signature. And making your own CA with all relevant OIDs is not enough, as kext signature checks are hardcoded to only accept Apple-rooted certificates. The only legal way to circumvent this is to pay Apple 100$/yr fee, essentially for using my own computer. That's why I would like to make anchor apple requirement to not only match certificated issued by Apple CA, but also for any trusted CA, including those provided by user, to make a publicly available patch as non-intrusive as possible, and now I am investigating how to do that.