[E-Lang] Re: Old Security Myths Continue to Mislead

[Marc Stiegler]

> Hmm. This strongly suggests to me that there is an important difference
> between OO and capability-based programming that I have not yet discovered
> how to articulate clearly. If capabilities are, as MarkM argues, simply
> "pure object references", then why is it that so little OO code translates
> successfully into capability systems without overhaul? Is this merely a
> reflection of the fact that well-encapsulated design is hard, and
therefore
> rarely done, or is there something more basic at work here? Anybody got a
> useful framing?
>
> Stiegler-san: since you've been describing E programming to an
introductory
> audience, have you any useful insights here? I haven't looked at "E in a
> Walnut" (time constraints), but it is beyond credence to think that you
> would successfully restrict yourself to "what to do" without discussing
both
> "how to" and giving some careful thought to motivating "why". Ideas?

As you surmise, I have thought about this a great deal. I do not have a
complete answer, but I have some observations:

1) In the special OO case of E code, code written without thinking about
security often translates directly to secure systems.

2) One of the parts of E where security requirements leap out at you is in
the development of "emakers", the E mechanism for building library packages.
emakers come to life totally confined, all the authority they need must be
passed in, there is no ambient authority (such as, in Java, "new
java.io.File("name")). As a consequence, library packages are noticeably
more difficult to build (though it is going to get much better in the
future, for reasons that are off topic and I can address separately if
people want to pursue it).

3) I hypothesize that one major reason Java code translates poorly to
capability systems is that the assumption of ambient authority is so
ubitquitous. It would be interesting for a grad student somewhere to walk
through a substantive Java system to see what percentage of major modules
assume ambient authority, I'd guess it is close to 100%. Believe me when I
say, unless you have written a few emakers, you have no idea how much
ambient authority you unconsciously assume when you are writing Java code
(well, the EROS and KeyKos guys may have an idea. But even for Electric
Communities, most of the coders could assume all the ambient local-platform
authority they could eat :-)

4) Another difference is that, while POLA is a good idea when building OO
software (because you can protect different parts of the system from
damaging each other by accident), it is a serious requirement in capability
secure systems. As a consequence of the change in level of importance, it is
not surprising that typical OO software follows, not the Principle of Least
Authority, but rather a "principle of less authority", which is often not
quite good enough and needs rewriting.

5) Finally, at the serious trust boundaries in complex systems, there are
specific patterns of interaction that are purely security-ensuring patterns.
One would not use these in an OO system without security requirements.
Looking at E in a Walnut on the Web, the patterns at the end of the chapter
on Secure Distributed Computing include the sealer/unsealer pair and the
notary/inspector pair, neither of which would be used except for security
reasons (though others of these patterns are perfectly reasonable OO
patterns for complex systems: pet names not only protect from forgery, but
from accidental name space collisions, and facets protect from accidental
damage as well as malicious damage).

I think this list is enough to explain why OO software rarely translates
well, though I'd bet there are additional reasons not in this list, even
though OO Programming on the surface looks very similar to
Capability-Oriented Programming.

--marcs