[cap-talk] In Defense of Identities - not

[Jonathan S. Shapiro]

Okay, let me try to tease apart some of the problems in this, because I
am worried that we are having divergent discussions.

To be clear: I'm not necessarily arguing for identities per se as a
basis of authorization (though they are needed as a basis for logging).
What's really going on is that I'm challenging the viability of the
membrane pattern in an OS-based implementation.

First, let me address something Jed said:

  Suppose that in addition to the above whenever a permission
  was delegated (either by being given or by being taken from
  a global post) it was labeled as to who it came from and who
  received it.

I just want to note in passing that the entire notion of "who" is very
problematic. Do we mean by this the user, or do we mean a more general
notion of stakeholder? Often, when people resort to "who", they are
engaged in the tacit assumption that programs act on behalf of their
users (perhaps not voluntarily, but still).

So we have a very fundamental definitional problem concerning the word
"who".

Okay. Back to membranes.

Membranes are a very attractive pattern and idiom, but they flatly don't
work as an operating system tool. There are several problems:

  1. In the presence of a trusted service you don't need them.
  2. In the absence of a trusted service you can't build them,
     because you cannot reliably obtain the object protocol.
  3. In the absence of a trusted service, it is exceptionally
     difficult to get transitivity of revocation right. The simple
     cases are simple and the hard cases are impossible. Consider:

        c1->someOperation(...arg...) => c2

     the decision to wrap the 'c2' capability depends a great deal
     on what 'someOperation' does.
  4. There are also issues of capability identity preservation.

Some of these (notable exception of 3) are more easily and efficiently
resolved in a language context. In an operating system context,
performance considerations strongly motivate implementing membrane-like
logic within the kernel. Unfortunately, there isn't an efficent way to
record capability interdependencies (and in any case issue 3 makes it
unclear what to record).

In addition, the introduction of membranes has to be done by a
surprising number of parties in context-sensitive ways. This introduces
several issues:

  1. It increases the set of objects on which we must rely.
  2. The context sensitivity of membrane introduction makes it very
     very easy to get it wrong.
  3. In the absence of a centralized implementation, it is unlikely that
     membrane enforcement will be consistently implemented.

shap
-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC
+1 443 927 1719 x5100