[E-Lang] draft statement of consensus

Marc Stiegler marcs@skyhunter.com
Tue, 6 Feb 2001 10:47:45 -0700

Hey, Jonathan,

There's a bunch of enhancements I want to do with Statements of Consensus
too. Extensibility for one. I have forced myself to hold back on
enhancements to get this one out. If we view this as an iterative process,
with a series of Statements, we can allow incomplete ones to get published
comfortably--it's the same way I get software development teams to actually
deliver a product, by saying, "yes, you're absolutely right, we need that
feature, and it is going first thing into Version 2.0". If you say, "but
version 2 never comes", well, with software groups that don't postpone to
version 2, version 1 never comes either :-)

I think early incomplete statements (even ones that we replace with more
refined statements in later publications) are immensely valuable. They help
establish a process that is proven to work. And we get to publish something
wonderful while we are certain we have the attention of the wonderfully
diverse collection of people who have contributed so far.

There is already noticeable overhead in changing this one, even if there
weren't the least controversy in anything you propose: even though we aren't
even a full day into the 4 day quiet period, I have already received 10
private emails of endorsement of this one. I have to throw those all away if
I change it as you propose.

> We might therefore consider appending to your list the following. I claim
> regard to X+4 that proof should dominate over concensus :-), lest we be

Actually, it depends on your goal. This is a Statement of Consensus, not a
Statement of Proofs.  These are 2 different laudable things that serve 2
different laudable goals. With a Statement of Consensus, we have a list of
participants at the end, all of whom can defend, and are willing to defend,
the statements. So future readers can go to the one they have the closest
personal relationship with to defend it. For many people who have a trust
relationship with at least one person in the participant list, just the
presence of that one person on the list is enough: they can ask that one
person if they agree (if they want to confirm that Marc Stiegler isn't
engaged in forgery), and simply believe it. Proof doesn't enter into the

A proof is useful for convincing someone who has the time and the context to
understand the proof. A consensus is useful for convincing someone who
trusts at least one participant, but is missing either the time or the
context for the proof. There are a lot more people who fall into the second
category than who fall into the first :-)

I will discard the current draft of the consensus if you cannot endorse it
as it stands. But if you can bear the existing one, please let me publish
it. Then we can move on to the next one.


----- Original Message -----
From: Jonathan S. Shapiro <shap@eros-os.org>
To: Marc Stiegler <marcs@skyhunter.com>; E Language Discussions
Sent: Monday, February 05, 2001 10:24 PM
Subject: Re: [E-Lang] draft statement of consensus

> MarcS:
> In my note, I suggested an example of an ACL-class system that may be
> (MLS). It hasn't been rebutted, and even MarkM seems to have agreed with

> forced by snout counting to reject the feasibility of confinement in
> capability-based systems. (If you didn't get "snout counting", you need to
> read Turtledove's WorldWar series).  While item (Y) has not seen
> I would be surprised if anyone disagreed.
> Item X+5 is quite cool. It only emerged in my head as I was thinking
> the implications of the equivalence class thing.
> X) We all agree that there are circumstances in which ACL-type protections
> can usefully be combined in hybrid form with capability-type mechanisms in
> order to more efficiently support certain types of security policies (such
> as MLS). In all the cases we know about these policies can be successfully
> implemented in pure capability systems with confinement, but we note that
> OS-based systems the runtime system (i.e. the OS) has very limited
> of the application semantics, and that as a result hybrid implementations
> may offer significant advantages of performance and flexibility over pure
> capability implementations.
> I'm thinking specifically that an MLS/ACL system allows some forms of data
> and program sharing that are hard to achieve efficiently using a pure
> capability mechanism.
> X+1) We all agree that one of the key weaknesses in ACLs lies in the fact
> that real implementations do not (and for reasons of efficiency cannot)
> conform to the Lampson Access Matrix. Specifically, ACLs in practice do
> describe (process, permission) pairs [the Lampson "subject" was a
> They instead describe (protection domain, permission) pairs, where the
> protection domain is some equivalence class. This equivalence class is
> typically an equivalence class reducing a large number of processes into a
> smaller number of categories (users, security levels, colors, or some
> This collapsing of the access matrix is a considerable reduction in the
> restrictive power and flexibility of ACL-based access specifications,
> is inherently problematic. Further, it is common in practice that the
> equivalence class function interacts badly with the security policies that
> are desired for the system. For example, neither the [process/security
> level] nor the [process/user-id] equivalence classes can enforce
> in the absence of an accompanying capability hybrid mechanism.
> X+2) We all agree that because of the equivalence class reduction
> present in all real ACL implementations, it is NOT true in practice that
> ACLs and capabilities are equivalent **even in the purely static view**.
> X+3) We all agree that the types of evolution in the protection graph that
> arises in capability systems are qualitatively different from the types of
> evolution that arise in typical ACL systems. The most important
> is that ACL systems commonly have a "universal grant" right, in which
> certain distinguished protection domains (those corresponding to owners)
> have the authority to grant access rights to other protection domains
> **whether or not the recipient agrees.**  It follows that ACLs and
> capabilities are NOT equivalent mechanisms when we take a dynamic view of
> the access graph, because they have qualitatively different operations for
> access right propagation.
> X+4) We all agree that for any ACL system having an "own" right of the
> previously described type, in the absence of some other protection
> mechanism, confinement can be violated in one step (a grant) regardless of
> the initial access graph configuration.
> X+5) We can show that for any ACL system s.t. |domains| < |processes| it
> impossible in general to enforce per-process confinement in the absence of
> additional protective mechanism. [Translation: if the number of things you
> get after you do the equivalence class compression is less than the number
> of total subjects] This follows trivially from the counting lemma. In the
> absence of additional mechanism, there must exist some process P that we
> might wish to confine and some second process Q s.t. domain(P) ==
> and it follows from this that either both must be within the confinement
> boundary (violating our initial goal of single process confinement) or
> outside (similarly violating our goal of single-process confinement. If P
> inside and Q is outside (or vice versa), it follows from domain identity
> that the two can access the same state. Ignoring the fairly dull case of
> processes with no mutable state at all, it follows that P cannot be
> from Q, and since either P or Q is outside, then its partner cannot be
> confined.
> This proof sketch does not preclude confinement in special cases in such
> systems; it merely points out that there is a close and potentially
> challenging relationship between the selection of an equivalencing
> and the feasibility of confinement in the resulting system.
> Y) We all agree with the "Principle of Consent" which I will now define:
> two parties are communicating, and neither can be said to be dominate the
> other (e.g. a debugger can dominate a subject process, as distinct from
> normal communication between peers), then the recipient of a communication
> should consent to all receipt of authority (or perhaps more broadly,
> consent to the receipt of any communication at all, but most especially to
> the receipt of authority). In practice, a reasonable realization of this
> that the recipient of a communication should be able to reject any
> authorities that the incoming message may offer.
> Jonathan