Re: Translucency counterexample

[Jonathan S. Shapiro]

On Fri, 2007-01-12 at 03:37 +0100, Pierre THIERRY wrote: 
> Scribit Jonathan S. Shapiro dies 11/01/2007 hora 20:36:
> > Ultimately, the only purpose of a ProcessCreator is to support
> > isInstanceOf(). Everything else that it does is pure convenience.
> 
> Would you have scenarios where only the branding can achieve the desired
> goal, and not only some capability exchange?

Yes. It is impossible to safely implement non-forgeable getType() as a
method of the object that you are asking. The best approximation that
can be implemented that way is getAllegedType(). That is: the object can
be relied on to say what behavior it *claims* to implement, but this may
not be what it actually does.

In some cases it is imperative to know what the actual behavior of an
object is. That is: you really need to confirm that the process obeys
some piece of code whose behavior you can rely on in some way. A
capability exchange protocol cannot test this.

It may be possible to come up with some mechanism other than brands, but
I kind of doubt it. Brands are a specific example of the sealer/unseal
design pattern, which is one of the very early patterns in the
capability literature. The pattern has been independently reinvented in
the PL world. The only alternatives I know about turn out to be
permutations of the sealer/unseal pattern.


A non-forgeable isInstanceOf() is pretty fundamental and pretty
powerful. It allows a capability to be transmitted via an untrusted
intermediary and then be authenticated by the recipient, *provided* that
the recipient has a previously obtained trusted means of authentication.
For example, I can hand you a capability to the password subsystem and
you can confirm that it is running the official "password" code before
disclosing your pass phrase to it. It may be a bogus *instance* of the
password subsystem, but you know that it respects secrecy of pass
phrases because you know that it obeys the same code as the official
password subsystem. You can determine this even though the capability
came from a suspicious source (i.e me). If you invoke it, only two
things can happen:

  1. It behaves according to specification.
  2. Somebody destroys the storage, but no disclosure occurs that
     would violate the specification.

Sometimes it is sufficient to know that the outcome must be one of these
things.

This entire design pattern, of course, fails completely if storage is
translucent.

In the example, your chain of trust is:

   1. You got the password instance constructor hierarchically
      from your parent, so you trust that.
   2. Therefore, you trust it to implement non-forgeable
      isInstanceOf()
   3. This can be used to authenticate the capability that
      arrived over the untrusted path, in much the same way that
      decryption can do this for bits over an untrusted wire.

This example illustrates that trust does not have to be purely
hierarchical. It can involve peer communications through untrusted
parties, and the ability to do this can lead to very interesting,
robust, and trustworthy assemblies of function even though the processes
that initiate the arrangement of the components may be unknown
(therefore presumptively untrustworthy). In this example, my trust of
the isInstanceOf verification mechanism arrived hierarchically from my
parent, but once I have this in hand I can build peer trust
relationships over instances without further involvement of the parent
hierarchy.

I have tried to describe this distinction about hierarchy and
non-hierarchy trust before, and I have fumbled. Marcus (and Hermann
Hartig) claim that all trust is hierarchical. I think this is not a
precisely accurate statement. I think that what is true is that all
trust must be *bootstrapped* hierarchically, but there are very
interesting and powerful lateral extensions that are possible given
non-forgeable isTypeOf and similar membership test operations. This is
one of the places where long experience with capability systems led me
to feel there was something that was very important, but that I was
still unable to clearly articulate to Marcus, Neal, or Hermann. Perhaps
I will now find out if I have done better this time. :-)


However, I should draw attention to two things here:

1, The ability to perform non-forgeable isInstanceOf() necessarily means
that capability simulation can be unmasked under normal conditions of
execution. There is a fundamental technical conflict of goals here.

My experience is that simulation can always be unmasked by a clever
enough agent, so it's better not to pretend about that and get the
advantages of non-forgeable isInstanceOf().


2. I do not know of any design pattern relying on non-forgeable
isInstanceOf() that is possible or useful in a system having translucent
storage. This [finally] explains why I was so strongly opposed to
translucent storage. It is unfortunate that I could not state until now
that broad class of design patterns that were disabled by translucency.
At least now we can examine them.


shap