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

[Bas Wijnen]

On Wed, May 03, 2006 at 08:39:24PM +0200, Michal Suchanek wrote:
> 1) confinement
> 
> We are talking about confinement all the time but there are
> misunderstandigs about meaning of the term.

I don't think so (but I may not understand what the others mean. :-) )

> Marcus suggests that confinement is the property that when a process
> is created it has acces only to certain limited resources that was
> given it on its creation.

Yes.  In general, confinement is that the new process can only talk to the
outside world through authorized channels.  The authorization is done by the
instantiator (see below for definition) by one of two methods:
- The capability is given to the process
- The capability is given by the constructor, but it is allowed by the
  instantiator via a bag which contains it.

> In marcus' proposal there is only one parent that creates the process.

Correct.

> 2) isolation
> Shap suggests that confinement means more. He designed a constructor
> that allows the created process to have two parents: a builder  - the
> constructor, and a requestor - a procaess that uses the constructor to
> create (instantiate) the new process. iirc when marcus is speaking
> about constructors he uses the term instantiator, and it is not clear
> if it means the builder or the requestor (probably the later).

I'm not sure if Marcus used that term as well, but I did many times.  To me,
the instantiator is the proces which wants the new process to be created.  In
case of Jonathan's model, it is the requestor.  In case of Marcus' model, it
is the (only) parent.  Furthermore, I call the newly created process the
child, and the one that's building it the parent.  In Marcus' model, the
parent == instantiator.  In Jonathan's model, the parent == constructor.  I
don't think I've talked about the process creating the constructor at all.
Jonathan calls that the builder.

> So let's stick to the terminology with builder.
> Now shap suggests that to guarantee process confinement the
> constructor should be able to prevent the requestor access the new
> process.

I don't think he said that.  If he did, then I indeed misunderstood what he
called confinement.  I think this is what he (and Marcus) calls encapsulation.
Jonathan did say that encapsulation is one of the things the constructor
mechanism provides.

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

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

signature.asc
Description: Digital signature