[cap-talk] Need Challenge Problems

[David Hopwood]

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.

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), 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.

> 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. 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.

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>