Chris@47: # Copyright (c) 2014 Sandstorm Development Group, Inc. and contributors Chris@47: # Licensed under the MIT License: Chris@47: # Chris@47: # Permission is hereby granted, free of charge, to any person obtaining a copy Chris@47: # of this software and associated documentation files (the "Software"), to deal Chris@47: # in the Software without restriction, including without limitation the rights Chris@47: # to use, copy, modify, merge, publish, distribute, sublicense, and/or sell Chris@47: # copies of the Software, and to permit persons to whom the Software is Chris@47: # furnished to do so, subject to the following conditions: Chris@47: # Chris@47: # The above copyright notice and this permission notice shall be included in Chris@47: # all copies or substantial portions of the Software. Chris@47: # Chris@47: # THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR Chris@47: # IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, Chris@47: # FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE Chris@47: # AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER Chris@47: # LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, Chris@47: # OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN Chris@47: # THE SOFTWARE. Chris@47: Chris@47: @0xb8630836983feed7; Chris@47: Chris@47: $import "/capnp/c++.capnp".namespace("capnp"); Chris@47: Chris@47: interface Persistent@0xc8cb212fcd9f5691(SturdyRef, Owner) { Chris@47: # Interface implemented by capabilities that outlive a single connection. A client may save() Chris@47: # the capability, producing a SturdyRef. The SturdyRef can be stored to disk, then later used to Chris@47: # obtain a new reference to the capability on a future connection. Chris@47: # Chris@47: # The exact format of SturdyRef depends on the "realm" in which the SturdyRef appears. A "realm" Chris@47: # is an abstract space in which all SturdyRefs have the same format and refer to the same set of Chris@47: # resources. Every vat is in exactly one realm. All capability clients within that vat must Chris@47: # produce SturdyRefs of the format appropriate for the realm. Chris@47: # Chris@47: # Similarly, every VatNetwork also resides in a particular realm. Usually, a vat's "realm" Chris@47: # corresponds to the realm of its main VatNetwork. However, a Vat can in fact communicate over Chris@47: # a VatNetwork in a different realm -- in this case, all SturdyRefs need to be transformed when Chris@47: # coming or going through said VatNetwork. The RPC system has hooks for registering Chris@47: # transformation callbacks for this purpose. Chris@47: # Chris@47: # Since the format of SturdyRef is realm-dependent, it is not defined here. An application should Chris@47: # choose an appropriate realm for itself as part of its design. Note that under Sandstorm, every Chris@47: # application exists in its own realm and is therefore free to define its own SturdyRef format; Chris@47: # the Sandstorm platform handles translating between realms. Chris@47: # Chris@47: # Note that whether a capability is persistent is often orthogonal to its type. In these cases, Chris@47: # the capability's interface should NOT inherit `Persistent`; instead, just perform a cast at Chris@47: # runtime. It's not type-safe, but trying to be type-safe in these cases will likely lead to Chris@47: # tears. In cases where a particular interface only makes sense on persistent capabilities, it Chris@47: # still should not explicitly inherit Persistent because the `SturdyRef` and `Owner` types will Chris@47: # vary between realms (they may even be different at the call site than they are on the Chris@47: # implementation). Instead, mark persistent interfaces with the $persistent annotation (defined Chris@47: # below). Chris@47: # Chris@47: # Sealing Chris@47: # ------- Chris@47: # Chris@47: # As an added security measure, SturdyRefs may be "sealed" to a particular owner, such that Chris@47: # if the SturdyRef itself leaks to a third party, that party cannot actually restore it because Chris@47: # they are not the owner. To restore a sealed capability, you must first prove to its host that Chris@47: # you are the rightful owner. The precise mechanism for this authentication is defined by the Chris@47: # realm. Chris@47: # Chris@47: # Sealing is a defense-in-depth mechanism meant to mitigate damage in the case of catastrophic Chris@47: # attacks. For example, say an attacker temporarily gains read access to a database full of Chris@47: # SturdyRefs: it would be unfortunate if it were then necessary to revoke every single reference Chris@47: # in the database to prevent the attacker from using them. Chris@47: # Chris@47: # In general, an "owner" is a course-grained identity. Because capability-based security is still Chris@47: # the primary mechanism of security, it is not necessary nor desirable to have a separate "owner" Chris@47: # identity for every single process or object; that is exactly what capabilities are supposed to Chris@47: # avoid! Instead, it makes sense for an "owner" to literally identify the owner of the machines Chris@47: # where the capability is stored. If untrusted third parties are able to run arbitrary code on Chris@47: # said machines, then the sandbox for that code should be designed using Distributed Confinement Chris@47: # such that the third-party code never sees the bits of the SturdyRefs and cannot directly Chris@47: # exercise the owner's power to restore refs. See: Chris@47: # Chris@47: # http://www.erights.org/elib/capability/dist-confine.html Chris@47: # Chris@47: # Resist the urge to represent an Owner as a simple public key. The whole point of sealing is to Chris@47: # defend against leaked-storage attacks. Such attacks can easily result in the owner's private Chris@47: # key being stolen as well. A better solution is for `Owner` to contain a simple globally unique Chris@47: # identifier for the owner, and for everyone to separately maintain a mapping of owner IDs to Chris@47: # public keys. If an owner's private key is compromised, then humans will need to communicate Chris@47: # and agree on a replacement public key, then update the mapping. Chris@47: # Chris@47: # As a concrete example, an `Owner` could simply contain a domain name, and restoring a SturdyRef Chris@47: # would require signing a request using the domain's private key. Authenticating this key could Chris@47: # be accomplished through certificate authorities or web-of-trust techniques. Chris@47: Chris@47: save @0 SaveParams -> SaveResults; Chris@47: # Save a capability persistently so that it can be restored by a future connection. Not all Chris@47: # capabilities can be saved -- application interfaces should define which capabilities support Chris@47: # this and which do not. Chris@47: Chris@47: struct SaveParams { Chris@47: sealFor @0 :Owner; Chris@47: # Seal the SturdyRef so that it can only be restored by the specified Owner. This is meant Chris@47: # to mitigate damage when a SturdyRef is leaked. See comments above. Chris@47: # Chris@47: # Leaving this value null may or may not be allowed; it is up to the realm to decide. If a Chris@47: # realm does allow a null owner, this should indicate that anyone is allowed to restore the Chris@47: # ref. Chris@47: } Chris@47: struct SaveResults { Chris@47: sturdyRef @0 :SturdyRef; Chris@47: } Chris@47: } Chris@47: Chris@47: interface RealmGateway(InternalRef, ExternalRef, InternalOwner, ExternalOwner) { Chris@47: # Interface invoked when a SturdyRef is about to cross realms. The RPC system supports providing Chris@47: # a RealmGateway as a callback hook when setting up RPC over some VatNetwork. Chris@47: Chris@47: import @0 (cap :Persistent(ExternalRef, ExternalOwner), Chris@47: params :Persistent(InternalRef, InternalOwner).SaveParams) Chris@47: -> Persistent(InternalRef, InternalOwner).SaveResults; Chris@47: # Given an external capability, save it and return an internal reference. Used when someone Chris@47: # inside the realm tries to save a capability from outside the realm. Chris@47: Chris@47: export @1 (cap :Persistent(InternalRef, InternalOwner), Chris@47: params :Persistent(ExternalRef, ExternalOwner).SaveParams) Chris@47: -> Persistent(ExternalRef, ExternalOwner).SaveResults; Chris@47: # Given an internal capability, save it and return an external reference. Used when someone Chris@47: # outside the realm tries to save a capability from inside the realm. Chris@47: } Chris@47: Chris@47: annotation persistent(interface, field) :Void; Chris@47: # Apply this annotation to interfaces for objects that will always be persistent, instead of Chris@47: # extending the Persistent capability, since the correct type parameters to Persistent depend on Chris@47: # the realm, which is orthogonal to the interface type and therefore should not be defined Chris@47: # along-side it. Chris@47: # Chris@47: # You may also apply this annotation to a capability-typed field which will always contain a Chris@47: # persistent capability, but where the capability's interface itself is not already marked Chris@47: # persistent. Chris@47: # Chris@47: # Note that absence of the $persistent annotation doesn't mean a capability of that type isn't Chris@47: # persistent; it just means not *all* such capabilities are persistent.