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

[Marcus Brinkmann]

At Mon, 01 May 2006 07:23:23 -0400,
"Jonathan S. Shapiro" <address@hidden> wrote:
> > As a very short summary,
> > the list is: IPC to system services, IPC between cooperating processes
> > (coordinated by a common parent), and communication between different
> > users/groups.  The latter class is the only one that requires special
> > consideration.  In this case, the communication must be tracable to a
> > legitimizing user action.
> 
> How does the system know that the IPC's are restricted to these cases?
>
> Marcus, my question was not asked for the purpose of confirming that
> "appropriate" IPCs are okay. It was asked for the purpose of
> illustrating that the set of legal operations in your system supports
> *all* of the allegedly immoral scenarios that constructors support.

There are three possible relationships a process and a second process:

(1) The second process is confined, but does not have _any_ extra
authority over the first process (this is what I call trivial
confinement).

(2) The second process is confined, but does have extra authority over
the first process.  In this case, it follows immediately that the
first process can only communicate with the second process because it
has an authorized channel.  This is what I call non-trivial
confinement.

(3) The second process is not confined.

First observation: I believe that this is a complete list.  It's a
coarse organization, but any specific example should fall into one of
the three groups.  Please let me know if you do not agree.

Second observation: I am fine with the relationships (1) and (3) under
certain situations.  I found appropriate use cases for either of them.
I gave you three examples, one example for (1) and two for (3) (the
two latter differ in how they justify the communication with an
unconfined process).

The question if IPC between processes with a relationship like (2) is
needed or not is _exactly_ the question that we are trying to resolve
in this discussion.  I put up a challenge to find out if there are use
cases relevant to the Hurd.  Tentatively I believe that there are
none.  If this is true or not remains to be seen, but I have done an
extensive survey and found that within the constraints of the Hurd, I
could elect an alternative mechanism belonging to the group (1) or (3)
instead.  Of course, these alternatives are not exactly identical, but
they are sufficient for my purpose (there is a matter of judgement
here).

To state it again, very clearly: I have no objection in principle
against communication between a process and a second, unconfined
process, in certain situations.

> > Some things are made harder by
> > it than I deem necessary (in particular issues related to
> > virtualization of services).
> 
> I find this statement *extremely* strange, since KeyKOS is one *only*
> object system in history that ever consistently demonstrated and used
> virtualization of services. Given that your statement is contrary to
> history, perhaps you will expand on it.

From the three groups above, only the relationship (1) allows full
virtualization, for example of the space bank, of the second process.
In the other two examples, virtualization is broken because the second
process has extra authority that presumably allows it to check the
authenticity of other capabilities.  This breaks virtualization.

In the case (3), this is desired.  In the case (2), it is also desired
by those who want to support it.  Because you have supported in the
past that _all_ process instantiations are of type (2), virtualization
of system services becomes virtually impossible.  In your language, it
would effectively be banned from the system.

Thanks,
Marcus