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 23:13:49 -0400

On Mon, 2006-05-01 at 04:44 +0200, Marcus Brinkmann wrote:
> 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.

I have a longer analysis coming, but let me send the first part, because
I think there is a very basic problem in your definition of "non-trivial
confinement". You wrote:

> With these definitions:
> 
> creator := the creator of the confined constructor object
> instantiator := the user of the confined constructor object
> 
> Then:
> 
> Trivial confinement     <=>  (creator == instantiator)
> non-trivial confinement <=>  (creator != instantiator)
> 

It appears to me that this definition is not enforceable unless IPC is
removed from the system entirely.

Here is my counter-example. Perhaps I have misunderstood you, or perhaps
you need new definitions.

1. I create a new constructor, so I am the creator. I put stuff into the
constructor. I instantiate programs. So far this is all just "trivial
confinement" as you call it.

2. In general, if I hold the ability to invoke an arbitrary process P,
and I also hold the ability to communicate with you, then I can send you
a capability that allows you to invoke process P. 

3. The constructor is merely a process, so I can hand you a capability
to the constructor.

4. You can now invoke the constructor, which is non-trivial confinement.

I do not see how to prevent this without disabling IPC altogether. What
am I missing here?

If you agree with statement (2), then your solution is not restricted to
hierarchy. It is restricted to the "rule of transitive introduction",
which is *exactly* the same rule that applied to the original
constructor mechanism.

I suspect that I am correct, and that your problem with the constructor
is not related to the instantiator vs. creator distinction. I will send
a longer note trying to break the constructor down feature by feature so
that we can learn which feature or combination of features creates the
problem.

But I definitely don't think that the instantiator/creator distinction
is relevant.


shap





reply via email to

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