[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 05:53:45 +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 23:08:15 -0400,
"Jonathan S. Shapiro" <address@hidden> wrote:
>
> On Mon, 2006-05-01 at 04:44 +0200, Marcus Brinkmann wrote:
> > > In case (B), I believe that this sort of "opaquely held" capability
> > > should count as a capability that the instantiating process does not
> > > have -- though I am not certain of this. There are handshake protocols
> > > here that could probably prevent DRM without going as far as you
> > > suggest, and I would like to explore these alternatives more carefully.
> > >
> > > But for the moment, can you also clarify how the capabilities of case B
> > > fit into your definition?
> >
> > They also count as capabilities that the instantiating process does
> > not have, if they are only opaquely held by the instantiator.
> > However: If they allow communication outward, then that means they
> > violate rule (3), because some behaviour by the instantiated process
> > (namely, an invocation of such a capability), can be observed by a
> > process not directly (or indirectly, in the way I explained)
> > authorized by the instantiator.
>
> By providing the bag to the constructor, the instantiator is authorizing
> the use of any capability in the bag, subject to the additional
> requirement that the capability is also stored within the constructor.
> This is very definitely an authorized capability in the sense of your
> rule 3 -- in effect, what is happening is that the instantiator is
> delegating a subset of its authorization decisions to whoever fabricated
> the bag.
Jonathan, I have given an explanation of what I mean with authorized
capability after my definition. Here is it again:
"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 capabilities in the bag don't fit this description, by which I stand.
I know how the bag mechanism works. In fact, I remember coming up
with it independently of KeyKOS in our discussions.
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