l4-hurd
[Top][All Lists]
Advanced

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

Re: Challenge: Find potential use cases for non-trivial confinement


From: Jonathan S. Shapiro
Subject: Re: Challenge: Find potential use cases for non-trivial confinement
Date: Sun, 30 Apr 2006 21:45:07 -0400

Marcus:

I have a technical question concerning your proposal. It appears to me
that there is a missing piece of case analysis here. I am not sure
whether it matters for what you are trying to ask, so I would appreciate
clarification.

You wrote, in part:

> (2) In this window of time, there is a point in time where the
>     instantiated process has at least one capability that the
>     instantiating process does not have.  (_Any_ capability counts).

In general, there are two types of "private" capabilities that the new
process might hold:

   A) (Transitively) read-only capabilities. These might include, for
      example, the capability to the program's initial code image.

   B) Capabilities that permit communication outward. In the EROS
      Constructor, this could be technically outside of your definition;
      in order to authorize this, the instantiating process must hold
      a "bag" containing this capability, but the bag is opaque. This
      means that the instantiating process cannot *use* this capability.

In case (A), I am not sure if the distinction here matters for the
purposes of your question. Assuming that the capabilities are
transitively read only, they are *completely* equivalent to stating that
the program holds a large constant number that is unknown (but in
principle available) to the instantiating process. However, without the
consent of the new process, there is no way to *confirm* which number
the new process holds.

I am not sure if this distinction is relevant, and I would appreciate
clarification about whether you really intend such a transitively
read-only capability to "count".

In case (B), I believe that this sort of "opaquely held" capability
should count as a capability that the instantiating process does not
have -- though I am not certain of this. There are handshake protocols
here that could probably prevent DRM without going as far as you
suggest, and I would like to explore these alternatives more carefully.

But for the moment, can you also clarify how the capabilities of case B
fit into your definition?


shap





reply via email to

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