Re: Translucency counterexample

[Marcus Brinkmann]

At Thu, 11 Jan 2007 20:36:08 -0500,
"Jonathan S. Shapiro" <address@hidden> wrote:
> 
> I have just come up with the anticipated example where read-only
> translucency would create a problem in EROS. It violates the
> isInstanceOf() mechanism.  My comment may make more sense after you look
> at the EROS brand mechanism in the note that I will publish very
> shortly.

[...]

> The problem is that the ProcessCreator was built with my storage. This
> means that I can inspect it, which means that I can extract the secret
> brand capability. The ability to extract the brand capability means that
> I can violate the integrity of the process type system. If this
> integrity is violated, the foundational chain of trust is broken because
> even the *primordial* servers cannot be reliably identified.

This is correct, but only if the primordial servers are instantiated
by subordinate or lateral programs.  In a system with translucent
storage this is obviously a very bad idea and a violation of a design
constraint.  As I said before, in such a system the resource hierarchy
must coincede with the trust hierarchy, which enforces a strong design
discipline in this regard.

As a counter example to your counter example, we have used something
similar to your branding mechanism in the Hurd's auth system
successfully.  Of course, the auth server is a system server
instantiated at boot time by the root filesystem (which sits at the
top of everything), and is never instantiated by subordinate or
lateral programs, unless it provides its service only to an enclosed
subsystem which is dominated by the instantiator.  For example, you
can run a second auth server to fake root authority while rolling tar
archives, so that the files in the tar archive are all owned by root
(fakeauth, used in Debian in conjunction with fakeroot).

Thanks,
Marcus