3 ms·

The fact that we went with access control lists instead of true capabilities has long been a disappointment to me. For people who understand OO, capabilities a

by btilly 10mo ago

The fact that we went with access control lists instead of true capabilities has long been a disappointment to me. For people who understand OO, capabilities are the simplest model in the world. You hand out objects. You can call methods on the object. What that method call has access to depends on the permissions on the object, not your permissions. Entire classes of security mistakes (most notably the "confused deputy" become impossible. The only commercial success that was a true capability system was the AS/400. Not coincidently, single stand alone machines averaged 99.99%-99.999% uptime. And it never had a significant security compromise. (Individual systems did, of course, have problems due to weak passwords and poor configuration. But they were still remarkably resistant. Capability systems work so well that when people wanted to improve security on Linux, they called it capabilities. Even though it wasn't. Unfortunately, the world went with ACLs. That's baked in to the design of things like Windows and POSIX. Which means that all of the consumer software out there expects ACLs. In order to get them to run on a pure capability system, you have to do things like create a POSIX subsystem. At which point, you've just thrown away the whole reason to use capabilities in the first place.

EGreg 10mo ago
I guess you must really love Capnproto then: https://github.com/iguazio/go-capnproto2 https://github.com/iguazio/go-capnproto2
- btilly 10mo ago
  Not sure why you think that my opinions about operating systems would predict my opinions about an RPC system.
  - kragen 10mo ago
    Possibly because Cap'n Proto includes a capability system that's currently widely deployed.
- ocdtrekkie 10mo ago
  You may want to change this link, this is an extremely old fork of the Go capnp implementation. It's neither official nor current! I'd recommend just pointing to capnproto.org
ryanjshaw 10mo ago
It’s bizarre to me that not one megawealthy tech nerd has thrown 8 figures at some smart people in an attempt to solve the capabilities-based OS UX problem. The payoff would be remarkable.
- csrse 10mo ago
  I guess Fuchsia is an attempt at a capability-based OS with wider appeal. The architecture seems interesting, wish there was quicker progress on it.
  - surajrmal 10mo ago
    It's honestly moving fast. OS are just complicated these days and it takes a long time to get to parity on all fronts.
- Jyaif 10mo ago
  The tricky part is not doing the capability-based OS, it's getting adoption. Linux is good enough, so a slightly better OS is not going to cut it.
Findecanor 10mo ago
The big problem is that you'd need to be able to change permissions over time. With ACLs that is simple and direct: if you have the access right, you just change the ACL. Traditional capabilities last forever, unless there is some sort of support for revoking already issued capabilities, and those mechanisms tend are far from straightforward. Some systems have revocation as a core feature, but a cascading revocation (every delegation as a branch in a tree, and revoke a whole subtree of delegated capabilities) is often complex and takes time, especially if they are on disk. There have also been protocols (for EROS-like OS:es) for setting up systems with additional capabilities to revoke individual capabilities but they are even more complex IMHO. So, in most capability systems the only way to revoke capabilities to a resource is to remove the resource itself. In CHERI, where every pointer is a capability, revocation of capabilities into a memory object relies on what is effectively a parallel garbage collector process that finds all pointers to revoked objects and overwrites them with an invalid pointer that traps on use. [0] In the fantasy OS of my mind, ACLs have instead been promoted to "access-control trees" that include a "grant option", allowing a user to grant the permission she has to someone else. But once the first user's permissions are revoked, the sub-tree of re-granted permissions get revoked as well. I think that could be achieved with existing file systems ACLs, with added topology info and enforcement by the OS. Then actual capabilities would be created first when a file is opened, as file handles, but unlike Unix file handles they could be revoked, be revoked in a cascading manner, and revoked automatically if the underlying ACT gets changed. Authorization Certificates (as in X.509) are a type of distributed cryptographic capabilities, but require complex distribution of "revocation lists". In recent years, there new types of distributed "authorization tokens" have been introduced such as e.g. "Biscuits" [1]. [0] https://www.semanticscholar.org/paper/Cornucopia-Reloaded%3A-Load-Barriers-for-CHERI-Heap-Filardo-Gutstein/80a3799d6b56fa25ea495129ee8b212ca6933500 https://www.semanticscholar.org/paper/Cornucopia-Reloaded%3A... [1] https://www.biscuitsec.org https://www.biscuitsec.org
- LoganDark 10mo ago
  > Traditional capabilities last forever, unless there is some sort of support for revoking already issued capabilities, and those mechanisms tend are far from straightforward. Capabilities don't have to hold the actual permission to access the object. Capabilities can simply hold a provenance that can be used to verify the source of the access. If that access is then revoked from that source, the capability doesn't need to change at all. This is similar to how generational arenas work in some game engines, IMO. AFAIK Android performs something similar to this with the storage URLs that are provided to apps, which will be different depending on which picker provided the file/media, etc. Apple probably also does something similar, but I'd imagine with objects rather than strings.
mikewarot 10mo ago
The thing that worries me about WASM is this exact conflict between compatibility with ACLs and security. It's like handing over your banking account authorization for every possible financial transaction, even if all you want to do is buy an ice cream cone. In the real world, capabilities based system, (aka a wallet with cash) you hand them a $5 bill, and wait for change.
- btilly 10mo ago
  You mean handing over everything needs to drain your bank account, like a check, instead of handing over a number that can be used to deposit money in your account, like the giro system that was developed in Amsterdam. After seeing the giro system in practice, I couldn't believe that we still use checks...

by btilly 10mo ago

EGreg 10mo ago

I guess you must really love Capnproto then: https://github.com/iguazio/go-capnproto2 https://github.com/iguazio/go-capnproto2

btilly 10mo ago
Not sure why you think that my opinions about operating systems would predict my opinions about an RPC system.
- kragen 10mo ago
  Possibly because Cap'n Proto includes a capability system that's currently widely deployed.
ocdtrekkie 10mo ago
You may want to change this link, this is an extremely old fork of the Go capnp implementation. It's neither official nor current! I'd recommend just pointing to capnproto.org

ryanjshaw 10mo ago

It’s bizarre to me that not one megawealthy tech nerd has thrown 8 figures at some smart people in an attempt to solve the capabilities-based OS UX problem. The payoff would be remarkable.

csrse 10mo ago
I guess Fuchsia is an attempt at a capability-based OS with wider appeal. The architecture seems interesting, wish there was quicker progress on it.
- surajrmal 10mo ago
  It's honestly moving fast. OS are just complicated these days and it takes a long time to get to parity on all fronts.
Jyaif 10mo ago
The tricky part is not doing the capability-based OS, it's getting adoption. Linux is good enough, so a slightly better OS is not going to cut it.

Findecanor 10mo ago

The big problem is that you'd need to be able to change permissions over time. With ACLs that is simple and direct: if you have the access right, you just change the ACL. Traditional capabilities last forever, unless there is some sort of support for revoking already issued capabilities, and those mechanisms tend are far from straightforward. Some systems have revocation as a core feature, but a cascading revocation (every delegation as a branch in a tree, and revoke a whole subtree of delegated capabilities) is often complex and takes time, especially if they are on disk. There have also been protocols (for EROS-like OS:es) for setting up systems with additional capabilities to revoke individual capabilities but they are even more complex IMHO. So, in most capability systems the only way to revoke capabilities to a resource is to remove the resource itself. In CHERI, where every pointer is a capability, revocation of capabilities into a memory object relies on what is effectively a parallel garbage collector process that finds all pointers to revoked objects and overwrites them with an invalid pointer that traps on use. [0] In the fantasy OS of my mind, ACLs have instead been promoted to "access-control trees" that include a "grant option", allowing a user to grant the permission she has to someone else. But once the first user's permissions are revoked, the sub-tree of re-granted permissions get revoked as well. I think that could be achieved with existing file systems ACLs, with added topology info and enforcement by the OS. Then actual capabilities would be created first when a file is opened, as file handles, but unlike Unix file handles they could be revoked, be revoked in a cascading manner, and revoked automatically if the underlying ACT gets changed. Authorization Certificates (as in X.509) are a type of distributed cryptographic capabilities, but require complex distribution of "revocation lists". In recent years, there new types of distributed "authorization tokens" have been introduced such as e.g. "Biscuits" [1]. [0] https://www.semanticscholar.org/paper/Cornucopia-Reloaded%3A-Load-Barriers-for-CHERI-Heap-Filardo-Gutstein/80a3799d6b56fa25ea495129ee8b212ca6933500 https://www.semanticscholar.org/paper/Cornucopia-Reloaded%3A... [1] https://www.biscuitsec.org https://www.biscuitsec.org

LoganDark 10mo ago
> Traditional capabilities last forever, unless there is some sort of support for revoking already issued capabilities, and those mechanisms tend are far from straightforward. Capabilities don't have to hold the actual permission to access the object. Capabilities can simply hold a provenance that can be used to verify the source of the access. If that access is then revoked from that source, the capability doesn't need to change at all. This is similar to how generational arenas work in some game engines, IMO. AFAIK Android performs something similar to this with the storage URLs that are provided to apps, which will be different depending on which picker provided the file/media, etc. Apple probably also does something similar, but I'd imagine with objects rather than strings.

mikewarot 10mo ago

The thing that worries me about WASM is this exact conflict between compatibility with ACLs and security. It's like handing over your banking account authorization for every possible financial transaction, even if all you want to do is buy an ice cream cone. In the real world, capabilities based system, (aka a wallet with cash) you hand them a $5 bill, and wait for change.

btilly 10mo ago
You mean handing over everything needs to drain your bank account, like a check, instead of handing over a number that can be used to deposit money in your account, like the giro system that was developed in Amsterdam. After seeing the giro system in practice, I couldn't believe that we still use checks...