[E-Lang] draft statement of consensus

[Jonathan S. Shapiro]

MarcS:

In my note, I suggested an example of an ACL-class system that may be useful
(MLS). It hasn't been rebutted, and even MarkM seems to have agreed with it.
We might therefore consider appending to your list the following. I claim in
regard to X+4 that proof should dominate over concensus :-), lest we be
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 discussion,
I would be surprised if anyone disagreed.

Item X+5 is quite cool. It only emerged in my head as I was thinking through
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 in
OS-based systems the runtime system (i.e. the OS) has very limited knowledge
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 not
describe (process, permission) pairs [the Lampson "subject" was a process].
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 such).
This collapsing of the access matrix is a considerable reduction in the
restrictive power and flexibility of ACL-based access specifications, which
is inherently problematic. Further, it is common in practice that the chosen
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 confinement
in the absence of an accompanying capability hybrid mechanism.

X+2) We all agree that because of the equivalence class reduction mechanism
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 distinction
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 is
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) == domain(Q),
and it follows from this that either both must be within the confinement
boundary (violating our initial goal of single process confinement) or both
outside (similarly violating our goal of single-process confinement. If P is
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 isolated
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 function
and the feasibility of confinement in the resulting system.


Y) We all agree with the "Principle of Consent" which I will now define: if
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, should
consent to the receipt of any communication at all, but most especially to
the receipt of authority). In practice, a reasonable realization of this is
that the recipient of a communication should be able to reject any
authorities that the incoming message may offer.



Jonathan