l4-hurd
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]