Operating systems are also written by programmers. An operating system written in a capability-safe language would not have such ambient authority problems.
An Operating System is a program that multiplexes hardware resources and makes them safely usable by a number of applications. If the design of that system is flawed, how could a capability-safe language do anything to correct the problem?
It is my assertion that the design of Linux, Windows, MacOS are all flawed. They provide, by default, any program the computer equivalent of "power of attorney". All you have to do is confuse, or subvert any program the user runs one time to abuse that privilege on behalf of an outside influence, and the system is on the way to being pwned.
Memory safe, and even capability safe languages won't do any good, if the underlying OS doesn't enforce the will of the user, but instead freely gives the users authority to any program they happen to run, intentional or otherwise.
I'm not saying memory or capability safety isn't useful, I'm just saying it isn't sufficient.
A capability-safe language safely multiplexes hardware and software resources among different parts of the same application. So, even if every application has the privilege to crash your computer, delete all your files, or exfiltrate your Bitcoin and ssh keys, not all the code in the application would. For example, your logging library doesn't need those authorities, so the rest of the program wouldn't pass them in.
> Memory safe, and even capability safe languages won't do any good, if the underlying OS doesn't enforce the will of the user, but instead freely gives the users authority to any program they happen to run, intentional or otherwise.
It is necessary to enforce the user's desired limits the authority on each application to prevent damage from malicious applications, but capability-safe languages (or hardware, like CHERI) can in most cases prevent damage from confused applications and from confused or malicious libraries.
> I'm not saying memory or capability safety isn't useful, I'm just saying it isn't sufficient.
I agree, but capability safety properly integrated with the user interface may be sufficient, as long as the capability system is sufficiently expressive to express the will of the user. (For example, KeyKOS's capability system includes keys to use limited amounts of CPU time, while E has no effective way to keep malicious code from denying access to a whole vat once it starts running; killing a running process because they're using too much CPU or memory requires some way to recover from their failures, which E does not have.)
A concrete example is the Network capability mentioned in the article. The syscall to create a new process does not need network access, so in a capability-safe language that part of the OS won't have that capability passed in, so the OS won't be able to create new processes with network access. The Network capability, if desired for this process, will need to be explicitly added later by other code, in the OS or in userspace.
Obviously that's not true.
Nevertheless, if you wrote OpenSSL in Rust, or any memory-safe language, it would not have those memory-unsafety vulnerabilities.
The same applies when writing in a capability-safe language. It's fairly deliberately ignorant to call these kind of properties "magic".