alt Hacker NewsI understand why in 1979 and perhaps until mid 1990s capability OS architecture might have been irrelevant and excessive. But after that, it sounds like the only architecture suitable for the internet age, where you can download and run anything from anywhere. Instead, we're stuck with legacy systems, which now contain layers of layers of abstractions and security measures. User rights, anti-virus software, vetting (signatures, hashes, app-store verification) - all become obsolete or near-obsolete in a capability-based system where a program simply doesn't have access to anything by default. Part of the appeal of virtualization is also due to the fact that it isolates programs (for instance, I only run npm inside Docker container these days, because chances are some package will contain malware at some point).
Part of it is inertia, but part of it is ignorance. Enthusiasts spend tons of money and effort building another GPU enabled terminal or safe programming languages - and maybe that's fine, but I wonder what we could've accomplished if people were simply aware what a well-designed capability OS could be like, because this is literally the only OS paradigm in existence (that I know of) that's even worth any serious effort.
Replies
If you go through old CS OS texts on the matter, they really didn't have the same understanding of capabilities then as the later object-capabilities (ocap) model would introduce. Typically they would show an access control matrix, note that acls were rows and capabilities columns and note that they are duals of one another. They're the same, acls are easier to manage, done.
OP is arguably the first paper that introduces ocaps. Some of the issues are discussed in "Capability Myths Demolished" https://papers.agoric.com/assets/pdf/papers/capability-myths...
One word: Qubes.
None of those things become obsolete with capabilities.
You still need code signing because users need to be able to grant privileges in a way that sticks across upgrades. The object they want to privilege isn't a set of files on disk but a logical app as defined by (more or less) a brand name+app name even as it changes over time.
You still need antivirus software because users can be tricked into giving capabilities to programs that appear legit but are actually malicious.
Modern operating systems (iOS, Android) are capability oriented operating systems to the extent that makes sense. For some reason there's a meme that says capabilities are a magic wand that solves all security problems, but it's not the case.
> it sounds like the only architecture suitable for the internet age, where you can download and run anything from anywhere
Wasn’t that the reason why Microsoft went allout against Java? Write once, run anywhere. JVM was a “trojan horse” and theoretically could have dominated the world.
Why do signatures/hashes/app-store verification become obsolete with a capability-based system?
If a binary has the capability to withdraw money from my account, I don't want that capability given to just any binary.
The problem with any secure system is that they're not usable systems. Real applications and users expect to access anything from anywhere. That's the opposite of security.
In addition to capabilities, which implemented the principle of least privilege (and keep untrusted code sandboxed by default) there is a need for binary verification.
A check that a whatever is downloaded cannot exceed it's capabilities.
Part of the challenge is that hardware tried and has failed to be trustworthy in implementing security boundaries. The failure appears to be because a misalignment of incentives.
I think the premise of a capability based operating system can help a lot, but for something to work in the long term the incentives need to aligned.
Your point of view has an insidious lie at its core; that the user perfectly knows what she wants. That if we only give the user the ability to set capabilities, we will not need any other protection for her.
The reality is that we're water meatballs, we're so easy to fool, and we need the cold calculating power of code to protect us from ourselves.
I'll insert my standard plug for Genode/Sculpt OS here... Capability based, and used/maintained commercially:
OS design basically stagnated in the 90s. Sure, we had NT, but that was putting a dos flavoured suit on VMS. BeOS was promising, but fizzled out quickly. Everything else has either been research or for the embedded market.
It looks like you you may be interested in Qubes OS, security oriented operating system relying on strong, hardware-assisted virtualization: https://qubes-os.org. My daily driver, can't recommend it enough.
The Market has spoken, and people use standard consumer CPU/GPU-bodge architecture in cloud data centers. Sure there are a few quality of life features different from budget retail products, but we abandoned what Sun solved with a simple encrypted mmu decades ago.
The paper adds little to TCSEC/"Orange Book"/FOLDOC publications. Yet the poster doesn't deserve all the negative karma.
On a consumer CPU/GPU/NPU, software just isn't going to be enough to fix legacy design defects. Have a great day. =3
We kind of have the taste of what capability-based OS would look like in form of a web browser: you can open a web page with a potentially-malicious code and it doesn't have access to any of your files or sensitive data unless you explicitly allow it to.
We also have it on mobile operating systems, although some things are a rather coarse-grained.
On desktop there's just a lot of inertia. Everyone switching to a new thing is kind of impossible, and some simple add-on to existing systems would look like containers/docker.
I think capability-oriented programming languages might actually be an easier way to switch to that model, as it's much easier to adopt a new application than a new OS. E.g. with language-level capabilities (ocaps) you can implement a safe plugin system. That's pretty much non-existent now and is quite relevant - e.g. getting pwned via an IDE plugin is the reality.
So maybe a "new Emacs" can be a way to get people to adopt capabilities beyond what we already have in the browser/cloud/etc. - IDE written in a new programming stack which is inherently secure to the point of running potentially-unsafe plugins.