Program instantiation (was: Re: Translucent storage: design, pros, and cons

[Marcus Brinkmann]

At Fri, 12 Jan 2007 19:58:34 +0100,
Tom Bachmann <address@hidden> wrote:
> >> As I understand it, the constructor serves as a trusted "mediator", that
> >> allows to check the confinedness without constructing the process (in
> >> non-translucent designs), that is, to run a program that is untrusted
> >> without risking leakage, and without inspecting it.
> > 
> > In EROS/Coyotos, this is true. Actually, it is a certifier, not a
> > mediator (the constructor does not remain in the loop after creation).
> > 
> > However: you ignored the other thing I said. Simply having a common
> > place to encapsulate these algorithms is a sufficient reason to have a
> > constructor.
> 
> Yes. I completely agree to this (although, then, the constructor is not
> a directly relevant part of the design anymore wrt it's security
> properties, but merely a outcome of applying the "principle of
> separation" [I can't remember if it has been given a special name]).

I think that this arguments ignores the usefulness of having intimate
knowledge about the bundle in the constructor and the algorithm, and
even the algorithms used internally in the program for completing the
startup.

For example, if you want to replace the interpreter of a script with a
different version, you need to know which parts in the bundle of the
constructor belong to the interpreter and which belong to the script.
Another example: To link the program with different libraries than the
one included in the bundle, you need intimate knowledge about the
binary format and linking algorithms used.

This is an example were "transparent access" to the storage not just
means inspectability, but intimate knowledge about its structure.  If
you want to leverage the flexibility illustrated by the above
examples.  the algorithms to make use of this must be standardized and
exist outside of the bundle itself.

If that is a goal, then it seems not to make much sense to have the
algorithms twice, once in the bundle and once outside.  But after
removing the algorithms, the constructor is reduced to a bundle of
capabilities, which we normally call a directory.  (As for
confinement, I essentially agree with Tom).

The question of how the directory layout should be, and how these
directories are managed, is directly related to the question of how
software packages are maintained in the system and is a complicated
issue that deserves more attention than I can give it in this short
note.  But my tentative conviction is that instead of constructors, we
should have per-package directory structures on the one hand and
flexible instantiation algorithms in a library on the other hand.

I had this discussion with Jonathan several times, and the
philosophical difference is that I see the developer of a program only
in an advisory role towards the user.  Ultimatively, it should be
within the user's ability to override the developer's decisions, in
particular in a free software operating system.  What I describe above
are not sufficient requirements to achieve this, but necessary ones.

Thanks,
Marcus