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

[Michal Suchanek]

On 5/3/06, Bas Wijnen <address@hidden> wrote:

> > Now if isolation is what marcus does not want
>
> It is indeed, but he calls it encapsulation.  However, it's not just that.
> It's encapsulation combined with confinement.  Either of them can be
> implemented without a constructor.  The combination cannot.
>
> > I have one use case he himself mentioned a few times:
>
> That was me, not Marcus.  But never mind that. :-)
>
> > 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.
>
> The process that the administrator uses is indeed like a constructor, but it
> is what we call a service: A server waiting for requests and doing things when
> it gets them.  Effectively, the constructor provides a service as well.  The
> constructor is special in that
> - It can run the program on someone else's space bank, but the owner of the
>   space bank doesn't have the authority to look at it.

Since the administrator has the authority to give space to the
instantiated user session, and the authorty to revoke it yet he is not
allowed to look at the space it is pretty much the same as if the
session was running on his space with encapsulation.

> - It can be confined (and the confinement can be verified).
> If any of these is needed for your use case, then it is valid.
>
> However, I don't think they are.  It is certainly not confined, because the
> new user's session should be allowed to communicate with the world, in
> particular with the person who "owns" the session.  And it also doesn't need

A browser plugin will want to communicate with the user as well. Does
that mean that we cannot have a confined browser plugin? And you
probably will want to decide what capabilities a new user session has,
and create even very restricted (ie guest) sessions.

> to run on the administrator's space bank.  Instead it allocates a new
> subspacebank from the primary space bank.  This is important to make sure
> noone (and in particular the administrator) can spy on the user.
>
> > 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.
>
> While this argument isn't strictly correct, because not every process may have
> access to this constructor, I agree in principle that limiting the number to
> anything higher than 0 does not make much sense.  However, the idea is to
> limit it to 0, which (potentially) does make sense.

Thanks

Michal