>Changing a security model that has been used for decades to a more restrictive model is difficult, especially in something as complicated as macOS. Attaching debuggers is just one example, there are many similar techniques that could be used to inject code into a different process. Apple has squashed many of these techniques, but many other ones are likely still undiscovered.

> Aside from Apple’s own code, these vulnerabilities could also occur in third-party software. It’s quite common to find a process injection vulnerability in a specific application, which means that the permissions (TCC permissions and entitlements) of that application are up for grabs for all other processes. Getting those fixed is a difficult process, because many third-party developers are not familiar with this new security model. Reporting these vulnerabilities often requires fully explaining this new model! Especially Electron applications are infamous for being easy to inject into, as it is possible to replace their JavaScript files without invalidating the code signature.

It makes me sad that we are likely not going to see any new fundamental design rethink for security's sake in mainstream operating systems. It is cost prohibitive at this point to do something that gets security right for the world of 2022 and yet not break all the apps which would never be rewritten!

Mobile OSes were a good break off point as far as security goes but that came with a lot of functionality sacrifice.

Although something like QubesOS can theoretically dream of being semi-mainstream with support from hardware and OSS OS vendors like RH/Suse/Canonical or even Microsoft.