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

[Marcus Brinkmann]

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