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

[Marcus Brinkmann]

At Wed, 3 May 2006 20:39:24 +0200,
"Michal Suchanek" <address@hidden> wrote:
> Now if isolation is what marcus does not want I have one use case he
> himself mentioned a few times: the instantiation of user sessions.
> Here the administrator uses a constructor to create isolated
> processes. If he did not the user sessions would be inside his session
> and he could observe them.

This is readily replaced by a slightly different mechanism: The system
administrator invokes a service (provided by the machine holder[1]) to
create a session.  The root process of the user session is then a
sibling to the root session of the admin session in the process
hierarchy.

Note that the nominal machine holder is always able, at least in
principle, to observe the user.  This is true irregardless if the
machine holder is a local person, or the provider of the "trusted
computing" component.

[1] I am tempted to say "machine owner".  In the case of "trusted
computing" however, it is not ownership that is transfered, but almost
complete control.  So, "owner" is not exactly right and I need a new
word that is not quite as strong.

> In my view reducing the number of constructors from potentionally
> limited only by system memory to exactly one does not eliminate the
> concept of isolation (ie the software that wants it may request a
> separate user session for itself). So it is a needless limitation.

However, it is not isolation that is under discussion but isolation
and confinement at the same time.

Thanks,
Marcus