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

[Michal Suchanek]

On 5/19/06, Bas Wijnen <address@hidden> wrote:
> On Fri, May 19, 2006 at 03:11:56PM +0200, Michal Suchanek 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.
> > >
> > >> 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.
> >
> > I meant isolation to be confinement and encapsulation at the same time.
>
> But a user session will not be confined, now will it?  It must be allowed to
> communicate with the user, and the user must be allowed to communicate with
> other parts of the system/world, otherwise the session is pretty useless.

It depends. If you define communication with user as breaking
confinement then no user session is never confined. Most user sessions
will have many other capabilities as well. But some guest sessions can
be very restricted. And it should be possible to create such sessions
(ie when you install a system on an exhibition for demonstration
purposes).

> > Anyway, I think you are attacking the issue from the wrong angle. The
> > DRM distributors are concerned about the encapsulation of their code.
> > We are concerned about confinement.
>
> We might be concerned about encapsulation as well, but only encapsulation
> against programs, not against the user on whose behalf the encapsulated
> program is started.
>
> > Writing a system that is deliberately broken (and can be fixed) so
> > that it allows either encapsulation or confinement but not both at the
> > same time would do little for our cause. The DRM vendors would require
> > encapsulation, and would not care about confinement.
> >
> > That way we only make the use of DRM software less secure (and
> > priviledged because only an administrator can install it).
>
> No, an administrator could not install it.  Only the machine holder could, and
> he would need to break his system for it.  Perhaps they will ask this of
> people.  But I think this is the kind of limitation that they'll accept as
> "what we want isn't technically possible on this system".  Since it's not
> possible on other systems either, they will likely give up (just as they do
> now) and resort to less effective means of protection, which do allow reverse
> engineering, for example.

Since the administrator should not be able to observe user sessions
the DRM software can be installed in a new user session. Problem
solved.

Thanks

Michal