[E-Lang] Transposing the Access Matrix

[Marc Stiegler]

> Which raises another difference between capabilities and acls.
Capabilities
> are a model of secure computation, while acls are just a security model.
> Good modern languages for symbolic computation, whether they think of
> themselves as being primary about lambda or about objects, but designed
with
> no regard to security, are nevertheless usually close approximations to
pure
> capability systems.

And as a consequence, capabilities can be integrated into programming
languages to an extent that seems unlikely to be possible for acl systems,
with the result that you can get security much more cheaply (there's no such
thing as a free lunch, but no one objects to an extremely inexpensive lunch
:-).

When I wrote my first distributed E program, Echat, I wrote v1.0
intentionally disregarding security, figuring that I had enough to learn
without worrying about that. I was tremendously amused and impressed when I
did a security audit to ascertain what I would have to fix: I discovered
that it was already secure!  All powerful capabilities had been safely
confined as simple a consequence of modular object design. V1.0 did allow
the person at the other end of the chat to do some annoying things to you,
like pop dialog boxes at you that you'd wonder where they came from, but no
data or persistent powers leaked at all.

Just for the exercise, though, I went ahead and fixed the annoyances. The
fix involved perhaps 15 lines of code.

I have since written 2 other more serious distributed E programs, both
requiring serious security review. Only a handful of architectural decisions
were affected by the security requirements. All those decisions can, in
retrospect, be derived from 2 axioms:

1) Each subcomputation of a distributed computation must be done by a
machine that can be trusted with that subcomputation (in an electronic
marketplace, for example, the subcomputation of what shares to buy must be
conducted by a program running on the machine owned by the buyer of the
shares; on the other hand, the subcomputation of the transaction that
transfers the shares and the money between 2 parties must be done by the
marketplace machine, not by any of the machines belonging to share owners
:-)

2) Never hand the capability for an actual computation object to another
machine. Always create a facet specifically for communication, and make the
facet minimal (which is a physical implementation of the Principle of Least
Authority). It was my failure in Echat v1.0 to follow this axiom that left
me some annoyances to fix.

I know other axioms are required (Jonathan, Norm, et al might have a
gargantuan list of such axioms for all I know  :-) but these two will carry
you an amazingly long way given a capability-oriented programming language.

--marcs