Re: Capabilities interact nicely with Substructural Types and Reactivity

On Thu, Sep 12, 2013 at 8:41 PM, David Wagner <[email protected]> wrote:

>
> > Further, DeepFrozen and Immutable do not have the same fine-grained
> > security-by-composition benefits as object capability model; they do not
> > enable the deep interleaving of trusted and untrusted code. They are very
> > blunt force tools.
>
> I'm not sure I understand exactly how DeepFrozen or
> Immutable prevent the deep interleaving of trusted and
> untrusted code:


It isn't that they "prevent" this interleaving. In this context I meant
'enable' in the sense of 'makes easy'.

Object capabilities are great because they support fine-grained
interactions. One can use them to model very precise authorities and
protocols, and by doing so we pervasive 'soft' security (limiting damage)
instead of the egg-shell security of other systems. Communication, in the
form of constructing objects to participate in a protocol, becomes an
"interleaving" of code. These interactions can potentially represent
service extensions, software agents, overlay networks, creating a new
service by integrating multiple other services.

DeepFrozen and Immutable do not seem to offer this level of precise
interaction, composition, integration. Rather, they represent a very
lopsided interaction where one party holds all the power and the other
party has all the knowledge.


> I'm not sure whether it is valuable or desirable to interleave
> them at too fine a granularity.


When I was doing capabilities with actors model, I found a great deal of
value in very fine-grained interactions, i.e. down to the handshakes to
establish connections and build upon them. A service object would start
with just a 'connect(me)' method, where one would hand their own end of the
connection. Every message would continue the protocol. Eventually, one
would have a working relationship between two services - and then this
*relationship* itself becomes a service that can be further built upon.

Interesting webs can be constructed in this fashion, but I found some
aspects painful - e.g. ensuring data consistency, resource management,
robust failover.

With RDP, I essentially extracted that model inside and refined it. With
RDP the connections - the interactions - are the first-class objects in the
language. Composition operates on behaviors to construct larger behaviors.
The resources at the edges are no longer first-class objects, but rather
are 'accessed' by some behaviors. Similarly, the signals themselves are
implicit, not directly observed but just transformed, maybe duplicated,
then fed into another fine-grained interaction. The result is very
satisfying.

In hindsight, it even seems obvious.

OOP seems to pollute the concept-space by using objects for two very
different kinds of things. First, objects represent resources (data models,
filesystems, GUIs, etc.). Second, objects represent relationships with
resources (revokers, promises, messages or channels, etc..).  Object
capability model seems much more oriented to the latter than to the former.


> In the object capability world, we have a rule of thumb: make

trust distinctions explicit in the class hierachy.


Oh, wow. I'm glad I never heard that one.

The 'class' concept is already a monster with far too many responsibilities
- interface, instance of interface, representation, constructor,
 information hiding. I think OOP would be better off it it broke these
responsibilities into different primitives.

Adding yet another responsibility? Ouch.

I prefer to make trust distinctions based on "Trusted Path" (cf. Ka-Ping
Yee's Secure Interaction Design). To use a capability to a specific
resource, we must first locate it. We can do so by searching locations -
e.g. perhaps a powerbox, or a shared registry that might be private or
public. In general, we can trust a location only as much as we trust the
agents that have authority to publish to it.

Best,

Dave

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk