1. 19
  1. 9

    cf Ponylang for an implementation of this model: https://tutorial.ponylang.io/capabilities/

    1. 7

      Pony also has capabilities on external resources. For example, you need a capability to open a socket.

      1. 3

        This seems very similar to Rust’s borrowing model, and both of these are excellent!

        However, capabilities with regards to variables is only one part of the picture.

        I very much want my programs to be capability safe in terms of external resources too: the filesystem, exec, network access, etc. Functions and modules which require access to these would need to be provided them in order to utilize it.

        Monte implements this and has interesting demonstrations like https://monte.readthedocs.io/en/latest/taste.html#cooperation-without-vulerability which can safely eval() code from the internet. It doesn’t prevent an abusive user from using all the RAM or all the CPU, but it is impossible for the abusive user to read RAM, write to the FS, send spam emails, etc.

        EDIT 1 Additionally, capability safety doesn’t even have to apply to a single program! TahoeLAFS is a capability-safe networked filesystem.

      2. 8

        I was going to write a rant about how bad this page is, but it’s actually gotten a bit of a cleanup sometime in the past few months. Certainly, it’s no longer suggested that the page be merged with the one on RBAC, which is progress. Instead, I’m going to pick one thing missing from this page and talk about that.

        The biggest distinction between object-capability models and other capability models is that an object has rights. This is so intertwined with the history of object-capability discipline that the most well-known ocap language, E, put “rights” in their URL, erights.org.

        An object has a right to keep its closure of object references, its own capabilities, private from other objects. This right to privacy means that an object communicates only by passing messages, and that objects appear “unityped” or otherwise common since they all share a single unified messaging API. We can actually enumerate a series of corresponding rights:

        • Right to Privacy: An object’s closure is effectively sealed (as if by a brand sealer), and the unsealers are closely-held only by the object itself and a few runtime objects, particularly the interpreter and debugger.
        • Right to Anonymity: An object has no inherent name. An object is known only by its identity, and shall only be compared by others by consenting and conforming to a comparison API.
        • Right to Be Forgotten: If no references to an object are held by anybody else, and there are no more messages left to deliver to the object, then the object might as well not exist, and has the right to be garbage-collected or otherwise permanently abandoned; no more references should be forged to it.
        • Right to Safe Computation: Even if every single name in the “safe” scope, which is typically available, is taken away, and even if all of the syntactic sugar is removed, objects still can create some primitive values, like functions and integers, and do basic arithmetic. Languages vary greatly in how much power is granted; Pola is complete for P, Monte’s kernel language is (Turing-)complete for RE, and ActorScript’s author claims that their technique is even more powerful, although I still would like to see them implement it.

        Specific to Monte (which I work on) and other members of the E family are some additional rights:

        • Right to Due Process, or “no stale stack frames”: Calling an object immediately, by passing it a message and then waiting for the runtime to complete evaluation, is non-blocking. Only infinite loops (due to Turing-completeness) can prevent a call from returning, and only that or a thrown exception can prevent control from returning.
        • Miranda rights: When an object is created, if its script is missing some essential methods for existing in object-society, then they will be provided automatically. These are known as Miranda methods. In addition, some keyword arguments are added to every passed message. This Miranda protocol facilitates error propagation, pretty-printing, the opaque and uniform object API, and more.

        Objects have rights because objects do not have to trust each other in order to compute, only pass messages between each other.

        1. 5

          There is an informative series or articles from one of the Midori authors which includes object-capabilities as provided/defined/enforced by the kernel, see Midori: Objects as Secure Capabilities.

          1. 2

            Joe’s series is awesome. Highly recommended.

          2. 1

            Google’s new operating system, Fuchsia, is self-described as a “modular, capability-based system”, for another example of modern systems that are organized along these lines.

            https://fuchsia.googlesource.com/docs/+/master/the-book/