[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Challenge: Find potential use cases for non-trivial confinement
From: |
Marcus Brinkmann |
Subject: |
Re: Challenge: Find potential use cases for non-trivial confinement |
Date: |
Mon, 01 May 2006 04:44:56 +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 Sun, 30 Apr 2006 21:45:07 -0400,
"Jonathan S. Shapiro" <address@hidden> wrote:
>
> 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".
I think they count, just as I stated.
> 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?
They also count as capabilities that the instantiating process does
not have, if they are only opaquely held by the instantiator.
However: If they allow communication outward, then that means they
violate rule (3), because some behaviour by the instantiated process
(namely, an invocation of such a capability), can be observed by a
process not directly (or indirectly, in the way I explained)
authorized by the instantiator. The program is not confined in the
sense of rule (3).
I had to add rule (3), because I needed to exclude non-confined system
services that spawn worker processes. Tentatively, I think the bags
are really only necessary to fix up problems that pop up when you
start with a non-bag use case, if that is true than starting with an
empty bag does not pose a serious limitation of the case analysis. If
you have a more interesting use case for bags, we can run this outside
the competition ;)
The meaning of the challenge, as proposed, is actually a very simple
one: The claim is that a strictly hierarchical process tree based on
the simple parent-child relationships is expressive enough for the
Hurd.
Thanks,
Marcus
Re: Challenge: Find potential use cases for non-trivial confinement, Pierre THIERRY, 2006/04/30
Re: Challenge: Find potential use cases for non-trivial confinement, Pierre THIERRY, 2006/04/30
Re: Challenge: Find potential use cases for non-trivial confinement, Pierre THIERRY, 2006/04/30