|
| ▲ | jdougan an hour ago | parent | next [-] |
| 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... |
| |
| ▲ | jkhdigital 22 minutes ago | parent [-] | | I’m not going to argue against much of the content of this paper, but it should be pointed out that their argument in the middle section against the “confinement myth” seems pretty bogus. They say that you can isolate the capability read/write resource from the data read/write resource, but… this makes absolutely no sense. Bits are bits. If you assume some out-of-band isolation of capability distribution then you’ve changed the game, but even that isn’t enough for me to believe that isolation is possible. |
|
|
| ▲ | mike_hearn 30 minutes ago | parent | prev | next [-] |
| 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. |
|
| ▲ | haunter an hour ago | parent | prev | next [-] |
| > 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. |
| |
| ▲ | usrbinenv an hour ago | parent [-] | | I didn't mean it in the Java way. I meant that whatever operating system you're on, you can download random programs from the internet (compiled specifically for your OS or portable) and run it on your machine. It doesn't matter what they're written in or how they're run, it's possible on any OS connected to the internet and an OS with capabilities as first class citizens would isolate any program by default, denying it access to anything by default and severely limiting program's ability to cause harm, intentionally or unintentionally. |
|
|
| ▲ | myaccountonhn an hour ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | usrbinenv 32 minutes ago | parent [-] | | In case of updating the binary, yes, you generally want to make sure it comes from the same source and therefore cannot do damage to things it already has access to. But when you install a new program, it shouldn't have access to any resources other than the ones it creates itself, so there's no need to sign it. Further more, when installing a new program, you still have to download/import the pubkey to verify the signature from somewhere, so it's almost meaningless on the first installation. Signatures wouldn't be obsolete, but they also wouldn't be the only line of defense. Furthermore, updating can now be performed by the program itself and the program might already contain the pubkey needed to check the validity of updates. |
|
|
| ▲ | fsflover 34 minutes ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | usrbinenv 30 minutes ago | parent [-] | | I know about it, but I'm not interested in QubeOS approach. It's VMs all the way down, while what I'm talking about is no VMs and capabilities as first class citizens and no vurtualization. | | |
| ▲ | fsflover 23 minutes ago | parent | next [-] | | What is wrong about virtualization? It allows to run all existing software, it doesn't restrict the owner of the device, it is extremely flexible and reliable. And it can be fast, too. | | |
| ▲ | Joel_Mckay 18 minutes ago | parent [-] | | see other comment, the author describes some issues with current hardware virtualization. kvm is also pretty good, but not perfect... and completely irrelevant with GPU pass-through enabled. =3 | | |
| |
| ▲ | Joel_Mckay 20 minutes ago | parent | prev [-] | | Qubes OS was also shown to have inherent hardware virtualization sandbox vulnerabilities described by Joanna Rutkowska in an interesting lecture. There is likely a PoC around someplace if people dig a bit. =3 | | |
|
|
|
| ▲ | Joel_Mckay an hour ago | parent | prev [-] |
| 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 |
