[E-Lang] Summary for Practical Programming

Marc Stiegler marcs@skyhunter.com
Thu, 1 Feb 2001 14:15:50 -0700


We've had a fascinating collection of discussions in these past days. They
have been sometimes-arduous discussions, however, and so at this moment I
feel like a summary of some sort might be useful, if not to us who have been
involved, than at least to others who might be interested in the results
tomorrow.

I would also like to draw some conclusions from the discussion for future
audiences as well. Email is great for discussion of ideas, but almost
useless for creating a decision like, "yeah, X is better than Y".

The approach I will try to take in the next paragraphs is somewhat based on
the "fact forum" ideas from some schools of decision analysis. Namely, I
will attempt to create a list of statements that everyone would agree with.
My chances of success on a first round are limited, particularly since I
want to try to get to some conclusions stronger than, "everyone disagrees"
:-)

In response to this email, if there is a point you disagree with, a simple,
"I disagree with that" is probably sufficient, a long rebuttal to this
summary may be less useful than is a continuation of the discussions in the
current threads. My only goal here is to see if I can extract some serious
substance from this, not to light off another thread (unless another thread
is needed :-) I am also interested in hearing other candidate statements
from folks for substantive, powerful assertions that they think everyone
would agree with.

Sometimes one must try the impossible, like gaining consensus, so here goes:


1. We all agree that currently available ACL systems are too broken to be
serious contenders for general-purpose effective security. I draw this
conclusion from the fact that the discussions always wound up veering into
discussions of theoretical ACL systems, not actual ones, when the going got
tough.

2. We all agree there is at least one security relationship that
capabilities cannot create, even in theory. This is the one Ralph Hartley
identified that markm agrees with. We also agree that this one is not of
practical importance. We also agree that there may be others that might be
of practical importance, though there is no agreement that others have been
found (i.e., Ralph listed some others, markm refuted them, and the
conversation terminated at that point, so I presume it is still a matter of
disagreement unless Ralph agrees with markm that the others are refuted :-)

3. We all agree that capabilities systems as embodied in EROS and E seem
architecturally sound enough to be serious contenders for providing
general-purpose effective security. I draw this conclusion from the fact
that the discussions always veered around to making theoretical ACL systems
live up to the standard set by what can actually be done in E and EROS today
(note I am saying they are architecturally sound, not that they don't have
actual implementation flaws in the versions you can download today). This
agreement is constrained by the limits on each individual person's actual
knowledge of E and EROS, but no one knows of anything about E or EROS which
contradicts this statement.

4. We all agree that capability systems lend themselves more easily to code
reuse than ACLs because you don't have to go back into the existing code to
create new mechanism for new refactored forms of security, you can just wrap
the existing system in a capability disciplined way.

5. We all agree that the Principle of Least Authority is an important
element in security design. Actually, I haven't yet heard back on my
assertion that POLA seems necessary as a best-practice, so it is more likely
that someone will disagree with this one than the others here, but it seems
sound enough to me that for a first draft of this document, I will include
it :-)

6. We all agree that POLA is an inherent characteristic in the nature of
capability systems, and to the various extents that each individual in this
discussion knows the actual behaviors of these implementations, POLA is a
part of both E and EROS as actual implementations.

7. We all agree that defense in depth is appropriate within the following
constrained understanding of defense in depth: At the levels above the
deepest level of infrastructure, we agree that using POLA, which in some
sense is a defense in depth, and using multiple patterns of interaction
(facets, revokable forwarders, sealers, etc.) to defend the system all make
sense. We still disagree as to how many kinds of defense are required at the
deepest level of infrastructure, i.e., whether just capabilities are
sufficient or whether others are needed.


For an Practical Programmer reading this summary, then, I personally would
draw the following conclusion: if  you want to build a complex flexibly
secure system starting this afternoon, the place to start is either with E
or with EROS or with both. Starting with Unix and C++ is just a bad choice.

Just trying to make sense out of this rich and wonderful discussion for
future generations :-)


--marcs