At Thu, 11 Jan 2007 20:36:08 -0500, "Jonathan S. Shapiro" <[EMAIL PROTECTED]> 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 _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
