l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Part 2: System Structure


From: Marcus Brinkmann
Subject: Re: Part 2: System Structure
Date: Wed, 24 May 2006 13:55:47 +0200
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Wed, 24 May 2006 12:53:27 +0200,
"Michal Suchanek" <address@hidden> wrote:
> 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.

You are using the words "trust" and "security" several times, without
saying who trusts whom and what you mean by security.  I don't want to
be anal, but these discussions can not happen at a marketing-buzz
level.  My suspicion is that the examples you are talking about are
(intentionally) not supported in my design, and that we differ not in
an assessment on what is technically doable or not, but on the
objectives.  There are types of "security" which I am interested in
supporting, and types of "security" to which I object.  Some examples
that I have seen where on the fence.  For example, the ping example
was a case where I think that we could very well agree on alternative
mechanisms that achieve some of the goals you want without going all
the way.  Note that one goal of the Hurd is to _reduce_ system code
and to maximize flexibility.

> 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.

Yes, the machine owner, the admin and the TCC manufacturer each have a
DoS attack against the user in the TC case.

Thanks,
Marcus





reply via email to

[Prev in Thread] Current Thread [Next in Thread]