[cap-talk] Need Challenge Problems

[Jed at Webstart]

At 12:24 PM 7/19/2006, David Hopwood wrote:
>Jed at Webstart wrote:
> > At 06:22 AM 7/19/2006, David Hopwood wrote:
> >>Mark S. Miller wrote:
> >>>Toby Murray wrote:
> >>>
> >>>>Also, the "confinement" term has also been used in the context of
> >>>>criticising unrestricted delegation. In this instance it has been used
> >>>>when talking about the "capability confinement problem" in
> >>>>http://www2.cs.uregina.ca/~pwlfong/Pub/esorics2006.pdf
> >>>
> >>>I just skimmed that paper, "Discretionary Capability 
> Confinement", by Philip
> >>>Fong. It seemed like he started out standing on some of the 
> right feet, but
> >>>then he lost me. Do you understand this paper? Can you explain it? Anyone?
> >>
> >>It goes in the wrong direction, IMO.
> >
> > I agree, and in so far as a scan can allow I also agree with the rest of
> > David Hopwood's analysis.
> >
> > In my opinion the failure of this sort of mechanism and similarly the
> > Rob Meijer mechanism are good examples of cases where the need 
> for what I refer
> > to as "network discipline" are abundantly clear.
>
>I don't really see what this has to do with networking. The problem discussed
>in the paper is easily solved in any pure capability system, and in 
>the same way
>regardless of whether it is language-based, a network protocol, or an OS.

Perhaps the problem ("discretionary capability confinement"), but certainly
not their approach to a solution - using as it does assumed shared methods
that can enforce capability granting policies, etc.  Such methods can't be
assumed to be shared across a network.

I argue that it's quite easy to get essentially "lost" in such mechanisms and
not realize that the mechanisms will not extend across systems with
distinct domains (only connected by networks capable of communicating
bits) across networks.  If the people working on such mechanisms were to
use the discipline of always extending any such mechanisms to independent
systems communicating on a network, then I believe the mechanisms would
end up greatly simplified and generally more useful.

>Despite the title of the paper, confinement is not an issue here 
>(the requirements
>did not state that Sidekicks need to be confined, and if they do that would be
>independent of the changes needed to "facetize" the Hero interface),

Hmmm.  I'm not sure I follow you there.  They certainly seem to think it is
when they say, for example, "the present goal is to restrict the forging and
propagation of abstractly typed references" (bottom of page 5).

>so it does
>not matter whether we are using an object capability system, or a 
>"capabilities
>as data" system. What is needed is simply to use an appropriate design pattern
>that follows POLA for this application. This is usually the case.

Sorry, but I don't understand the above.

> > This is partly why I put so much hope in mechanisms at the network level
> > (e.g. like YURLs or widewords) as I understand Tyler will be discussing
> > tomorrow (no pressure Tyler).
> >
> > In my opinion anything that can effectively work can work at the network
> > level.  At the network level it becomes quite clear what can be done and
> > what can't be done.
>
>Authority confinement is possible (and practical) at the OS and language
>levels, but not at the network level if we assume an open network.

If by "open network" you mean one (much like the Internet) where any process
can communicate with essentially any other process, then given the discussion
we've been having about conspiring communicators, that would seem to be
true.  It seems to suggest that authority confinement is essentially the same
as communication confinement (except for one way communication and such
special cases).

>Many people
>overestimate the significance of confinement, and see confinement problems
>even when the real issue is unrelated, but that does not mean that authority
>confinement is never useful, or that OS and language-based cap systems should
>not support it.
>
> > Once a scheme for communicating permissions
> > can be agreed to and standardized at the network level, then I believe
> > it's fairly straight forward to implement such a scheme at the OS and
> > even I expect at the language level.  Trying to go in the other direction
> > (start at, say, the language level or the OS level and try to extend to
> > the network level) I believe is a prescription for disaster - as 
> I believe we
> > have seen repeated again and again.
>
>I strongly believe that development of OS, language, and network capability
>systems needs to proceed in parallel. Any particular project has a relatively
>low chance of becoming popular (almost regardless of technical merit), so we
>need all the chances we can get.
>
>I think that cap-talk does a pretty good job of being a forum for cross-
>fertilization of ideas between these three types of system (and combinations
>of them). Perhaps more attention needs to be paid to minimizing unnecessary
>differences between systems -- for example, agreeing on a common data model
>or developing common library interfaces.

I believe that until permission communication (capability communication)
begins to happen at the network level there will be nothing effectively driving
any such common data models or common library interfaces.

For example, consider the Python work that was recently mentioned.  Is
there anything happening with that work that will share mechanisms with
any other capability work (e.g. E, Joe-E, etc.)?  While I can accept that in
principle a common language standard could arise that would bubble up
to the network level, that scenario seems unlikely to me.