Re: Translucency counterexample

[Jonathan S. Shapiro]

On Fri, 2007-01-12 at 19:17 +0100, Marcus Brinkmann wrote:
> Hi Jonathan,
> 
> is this intentionally off-list?

No. The problem is that l4-hurd is the ONLY list I am on that fails to
set reply-to, so it is easy for things to go off-list by accident. This
is the wrong default behavior, but mailing list theologians do not care.


> 
> At Fri, 12 Jan 2007 11:02:23 -0500,
> "Jonathan S. Shapiro" <address@hidden> wrote:
> > 
> > On Fri, 2007-01-12 at 16:18 +0100, Marcus Brinkmann wrote:
> > > At Thu, 11 Jan 2007 20:36:08 -0500,
> > > > 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.
> > 
> > I think you misunderstand. There is no reason why an arbitrary party
> > should not fabricate a process creator and/or a constructor.
> 
> Sure.  In the current Hurd system there is no reason why an arbitrary
> party should not fabricate an auth server as well.  But it would be a
> mistake for lateral or dominating programs to rely on that service in
> any way.
> 
> So, maybe in EROS there is some useful (to some) design pattern where
> arbitrary parties can fabricate process creators and constructors, and
> provide them to lateral parties, and everything still works as
> expected.  I am not sure I really understand this scenario, but I
> assume it exists.  Then this scenario is not supported in a
> translucent system, because of what I said above.
> 
> I think the relevant distinction here to make is the scope to which
> the service provided by the process creator and constructor is usable
> to others: In the EROS system, it seems to be laterally usable, while
> in a translucent system it is only usable by subordinated programs.
> 
> But it may well be that I am missing something still in your example.

Things are still coming to my mind in the middle of the night, but so
far I think this is a very good summary.

> > In a translucent system, your solution works mainly because the "real"
> > programs will all come in through the installer, and *that* storage is
> > only inspectable to God and root (which returns us to an earlier email).
> 
> It's a bit more general than that, but approximately yes.

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