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

[Marcus Brinkmann]

At Sun, 30 Apr 2006 19:01:25 -0400,
"Jonathan S. Shapiro" <address@hidden> wrote:
> 
> On Sun, 2006-04-30 at 23:17 +0200, Marcus Brinkmann wrote:
> > Propose a use case for non-trivial confinement.
> 
> Could you please define the term clearly, so that the discussion can be
> productive? I do not wish to mis-characterize what you are actually
> proposing.

Right, that's a good idea.  Here is the reformulated challenge that
avoids special terminology alltogether:

Propose a use case for process instantiation where the following
conditions are true:

(1) There is a time just before instantiation and just after
    instantiation where the instantiating process does not drop any
    capabilities.  (This requirement only sets up a definition that is
    used in the next requirement.)

(2) In this window of time, there is a point in time where the
    instantiated process has at least one capability that the
    instantiating process does not have.  (_Any_ capability counts).

(3) At no point in time (within or outside the window) can any
    behaviour of the instantiated program be observed by any process,
    except by the instantiating process and any process directly or
    indirectly authorized by it.  Assume that covert channels do not
    exist.

Instantiating a process means creating a new kernel process (the
instantiated process).  The instantiating process is the process being
directly or indirectly causative for the instantiation of the process.

End of definition.  What follows are explanations.

It should be clear that requirement (2) describes the constructor
mechanics, while requirement (3) corresponds to the confinement
property.

Note: It is obvious that _if_ the instantiating process can in
principle possess the extra-capabilities mentioned in (2), I can (and
will!) use that argument to propose an equivalent mechanism that does
not fulfill the above conditions, so it is to be understood that the
extra-capabilities in (2) are capabilities that the instantiating
process has in principle no access to.

"Encapsulation" is not included in this definition.  You may or may
not rely on it, your choice.  In particular, clause (3) does not
require that _all_, or in fact _any_, behaviour of the instantiated
process can be observed by the instantiating process.

The instantiating process can give capabilities that allow it to
observe behaviour of the instantiated process to other processes,
which can in turn give these capabilities to other processes.  This is
the meaning of direct and indirect authorization in clause (3).  The
assumption about the non-existance of covert-channel makes it clear
that in fact only authorized observations through capabilities are
meant.  This includes, however, capabilities to memory frames which
can then be shared.

Because this is on the spot, I reserve the right to revise this
definition if somebody should find a flaw in it ;)

Thanks,
Marcus