Re: Part 2: System Structure

[Michal Suchanek]

On 5/24/06, Marcus Brinkmann <address@hidden> wrote:
> At Tue, 23 May 2006 12:13:17 -0400,
> "Jonathan S. Shapiro" <address@hidden> wrote:
> > So: eliminating DRM does not require eliminating constructors. A
> > translucent space bank design is entirely sufficient. All of the rest of
> > the properties that you are worried to avoid are a consequence of
> > opacity. [It is possible that I have failed to consider something, but I
> > am fairly confident about this statement technically.]
>
> Although this is true, I always found the constructor quite an "in the
> way of doing things" mechanism, unrelated to the DRM discussion.  The
> reason is that the process composition happens too early for my taste.
>
> You believe firmly that the constructed program embodies the
> programmer's will, and you rely on this for various security
> arguments.  This is why the constructor mechanism is designed around
> the assumption that constructing the process is a separate operation
> from running an instance of the process.  So, in the constructor
> model, first all things are done to prepare a process image, or at
> least to allow the process to prepare its own image, then the
> requestor of the constructor instantiates it.
>
> However, I believe that there are many good and interesting
> applications where the instantiation operation influences heavily the
> process composition operation.  For example, in Unix, shared libraries
> are frequently replaced dynamically with LD_LIBRARY_PRELOAD or
> LD_LIBRARY_PATH, not only in development, to achieve various goals.
> Programs are run in specially prepared sessions, like ltrace, strace
> (Unix), rpctrace (Hurd), fakeroot, to observe or control their
> behaviour.  In the end, I want to make all types of virtualization and
> debugging very easy.  The constructor sometimes makes them harder, by
> putting a piece of infrastructure in the way of achieving these goals.

There see no reason why constructors would get in the way of such
tools. You sould be able to trace the capabilities you give. In the
cases the constructor gives a special capability you can still trace
how the capabilities you gave are used.
Admittedly you would have to create a new constructor for changing
libraries or tracing the capability inserted into the constructor. If
you have access to the capability yo can do so. If the constructor was
set up by an administrator or another user to perform some service you
cannot trace all aspects of the program because you should not get
direct access to the capability embedded in the constructor. That
sounds reasonable to me.
And I do not see why LD_LIBRARY_PATH should be so much of an issue.
Since the system allows confinement we should use the feature, and
implement most functionality as separate processes rather than
libraries.

> I learned from you that when you find you keep fixing a design, it
> probably is the wrong design to begin with.  There have been many
> proposals to fix the space bank + constructor design to allow it to
> support virtualization and debugging.  I think I do understand how,
> technically, I can recover my system design from the constructor
> mechanism by a couple of extensions.  However, if the constructor
> stands in the way of all the things I want to do, it seems opportune
> to ask why it should remain central to the design.
It depends. If it is a simpe change that allows us to get the system
we want I would not object against that. If it means fixups all over
the system it is obviously wrong.
However, it is not yet completely clear what system we want. So it is
not obvious which way it turns out.

Thanks

Michal