| All this code signing stuff is an admission of defeat. "Our OSes are insecure and we can't secure them, so fuck it." Unix and VMS/NT, the two most popular kernel lineages, were both designed when computers were either isolated or connected to an Internet that was effectively an academic/government walled garden. They absolutely were not designed to deal with the present information war zone where everything is trying to spy/hack/ransomware you and every piece of code is guilty until proven innocent. Since the Internet went mainstream we've been constantly stuffing wads of chewing gum into their many cracks, adding hack after hack to try to secure that which is not secure. Address layout randomization, pointer authentication hacks, stack canaries, clunky system call whitelisting solutions, trying to shoehorn BPF into a system call filtering role, leaky containers and sandboxes, and so on. Code signing is an admission that none of those measures have worked. A secure OS would be built from the ground up with security as a primary concern. It would be written in a safe language like Rust or perhaps even in a system that permits strong proofs of correctness. Every process would run with minimal required permissions. Everything everywhere would be authenticated. The user would have visibility into all this and would be able (if they desired) to control it, or they could rely on sets of sane defaults. There'd be no need for code signing on such an OS. You could safely run anything and know it would not be able to access things you didn't grant it permission to access. The web JavaScript sandbox is the closest thing we have to that but it's extremely limited. By providing a Turing-complete sandbox that can be generally trusted to run code from anywhere, it does show that such a thing is possible. (Mobile OSes look like they've kind of done this, but they haven't. They've just stuffed more chewing gum into the cracks in Unix and put a UI on top that hides it. They also "solve" the problem by nerfing everything.) |
As you point out, security engineers have been working for decades on a vast array of techniques to mitigate classes of vulnerabilities. There's no reason to believe this is something that can ever be finished. There will always be bugs, always. Code signing embraces that reality by making it much easier to contain bad programs after they get out into the wild. It is just another tool in the toolbox, as with all security mitigations.
It's silly to suggest that you can solve security by simply rewriting the entire OS in Rust; and in a modern OS, every process already does run with minimal required permissions, and authentication is generally enforced, and users do have visibility and control, at least by design. Sometimes things slip through, of course. That will still happen even in the shiny new world you're proposing.
The existence of JavaScript does not imply that a completely secure OS is possible. There's a rich history of JS bugs that have led to total compromise of the OS -- in fact, earlier in your comment, you listed several vulnerability classes that have disproportionately affected JavaScript VMs.