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

[Jonathan S. Shapiro]

On Mon, 2006-05-01 at 07:58 +0200, Marcus Brinkmann wrote:
> At Mon, 01 May 2006 01:29:54 -0400,
> "Jonathan S. Shapiro" <address@hidden> wrote:
> > > Ok, that was not clear.  The default libraries and services will make
> > > sure that the user does only execute programs from the user's own
> > > storage.
> > 
> > This STILL doesn't address my example. I started the program, and I
> > handed you a descriptor that allows you to send IPC to my program. The
> > entire point is that I have *not* permitted you to instantiate it
> > directly or control its storage -- even if we have a "naked" storage
> > allocator.
> > 
> > So the "naked allocator" restriction is not achieving the objective: the
> > user (in this case the recipient of the IPC capability) *still* cannot
> > examine the program they are executing.
> > 
> > So next we must remove IPC, or if we do not, we should admit that this
> > is an impossible objective and stop compromising the system architecture
> > in order to achieve it.
> 
> Processes in general do not send random IPC to other processes.

Marcus: just *once* would you answer the fucking question
straightforwardly? Every time you avoid a legitimate technical question,
my suspicion goes up that you do not *have* an answer, and that you are
simply ducking because you have not made a technical decision at all.
You have made a personal decision based on an objective that your
alternative design does not appear to satisfy.

I do not object if there is some property you wish to remove, and you
actually *do* remove it, and as a consequence you weaken or omit the
constructor pattern from your system. I object very strongly if you
throw away 15 years of experience without achieving any objective at
all.


> 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.


> 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.

shap