[cap-talk] Need Challenge Problems

[Toby Murray]

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?
>  
>
Sorry, I hadn't actually read it when I posted the above. I was looking 
for another paper that I'd forgotten the name of, that used the term 
"capability confinement problem" but instead found that one. I just 
found the original paper, here: 
http://fpl.cs.depaul.edu/rjagadeesan/ftp/neighborhood.pdf
"Static support for capability-based programming in Java", which I know 
some on this list are familiar with. (End of digression)

>In particular, is his "Heros and Sidekicks" game an interesting challenge 
>problem for language-based security? Can someone state the problem so that we 
>could think about meeting the challenge using just pure object-capabilities, 
>without any of this fancier type machinery. Or so that we could understand why 
>his proposed type machinery helps? Thanks.
>  
>
He describes a setup where instances of a Hero class keep a set of 
Sidekick instances. The Sidekick instances also act as Observers (in the 
usual Observer pattern) of the Hero. When the broadcast() method of the 
Hero class is run, it updates all Sidekicks by calling their update() 
method and passing a reference to itself (ie. a reference to the Hero 
object).

The problems they want to solve (I think) are:
1. Prevention of the creation of arbitrary new Sidekicks by Heros.
2. Heros stealing Sidekick references.
3. Sidekicks gaining authority that they shouldn't have through use of 
the Hero reference they're given when their update() method is called.

I don't see how Problem 1 should really be an issue if one follows the 
idea that upon instantiation, an instantiated object can have no more 
authority than its instantiator.

Problem 2 looks to me like the usual argument against delegation.

Problem 3 looks just like a failure to observe the "separate distinct 
authorities into distinct objects" principle.
A Hero exposes two different authorities. One authority is captured by 
the Observable interface, the other by the other Hero methods. If facets 
were used to separate these distinct authorities into distinct objects, 
then Sidekicks could be given a reference to just the Observable facet 
of the Hero (which would, by design, prevent them obtaining a reference 
to the other Hero facet(s)).

Or have I misinterpreted his problem?

>What other interesting challenge problems might we find in the literature of 
>the other access control schools? We'd like to gather together challenge 
>problems for comparing schools, in order to grow a "secure cooperation 
>shootout" wiki.
>
>  
>


-- 
Toby Murray
Advanced Computer Capabilities Group
Information Networks Division
DSTO, Australia

IMPORTANT: This e-mail remains the property of the Australian Defence
Organisation and is subject to the jurisdiction of section 70 of the
Crimes Act 1914. If you have received this e-mail in error, you are
requested to contact the sender and delete the e-mail.