Re: Part 2: System Structure

[Michal Suchanek]

On 5/23/06, Marcus Brinkmann <address@hidden> wrote:
> At Tue, 23 May 2006 10:46:34 +0200,
> Tom Bachmann <address@hidden> wrote:
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Bas Wijnen wrote:
> > >> I'd like to encourage everyone to consider this. It sounds like a viable
> > >> compromise
> > >
> > > What exactly is "this"?
> > >
> >
> > The proposal by jonathan:
> >
> > >   There are opaque and translucent banks. The difference is that
> > >   the opaque bank will not issue a given page more than once. A
> > >   translucent bank will, which is how the user gains access to
> > >   the content.
>
> Jonathan's proposal achieves technically what he wants to achieve by
> it.  However, to me, it's a compromise in the same way that the
> feature to run an executable in an e-mail attachment by clicking on
> the attachment is a compromise between the interests of virus
> developers and the users.
>
> Putting "dangerous" code at the bottom of the system, and then trying
> to recover safety by extensions, is not good system design.  I think
> everybody agrees with that.  We do not agree on an estimation what
> constitutes "danger", but if you read what I wrote in Part 1, you will
> understand why the above does not constitute a compromise for me.
>
> Also, please pay attention to what I wrote about the GNU project in
> part 1.  Supporting DRM is in direct conflict with the interests of
> the GNU project.  Thus, for a GNU project, there can only be
> compromises with legitimate (in the context of the GNU project)
> interests whose benefit compensates the involved risks (again, for the
> GNU project).

The constructor in Jonathan's systems is a powerful tool. It allows
running programs on user resources and trust that they perform in
certain way (cannot be tampered with).
This allows 'outsourcing' system (and other) services so that most of
them runs on user resources and only small and simple part resides in
the system.
This is central to most of the examples already mentioned, at least
those that can be specified enough to be considered valid. It makes it
possible to build very secure services much more easily than any other
system I can think of.

I just want to ask how this design pattern is replaced in your
(recursive) system. It seems that just leaving it out will make the
system much less secure because building secure services will become
much harder.

Note: there is a separate problem of the machine owner. Jonathan wants
protection from the machine owner but it looks like it is
inappropriate for the Hurd. We do not want TPM, and that is the only
way of protection from the machine owner. On the other hand, good
protection from unauthorized access (network or terminal) is still an
improvement over current systems. And one has to trust the machine
owner in many other ways. For one, if you store valuable data on the
system you want a backup that can be read on another system as well.
If the data was protected by TPM it would not be possible.

Thanks

Michal