[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Challenge: Find potential use cases for non-trivial confinement
From: |
Marcus Brinkmann |
Subject: |
Re: Challenge: Find potential use cases for non-trivial confinement |
Date: |
Mon, 01 May 2006 02:44:46 +0200 |
User-agent: |
Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI) |
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
Re: Challenge: Find potential use cases for non-trivial confinement, Pierre THIERRY, 2006/04/30
Re: Challenge: Find potential use cases for non-trivial confinement, Pierre THIERRY, 2006/04/30
Re: Challenge: Find potential use cases for non-trivial confinement, Pierre THIERRY, 2006/04/30