[cap-talk] Need Challenge Problems

[David Hopwood]

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.

# The problem manifests itself in two ways.
# 1. [...]
# 2. Capability Leakage. A code unit in possession of a capability may
#    intentionally or accidentally "push" the capability to code units
#    residing in a less privileged protection domain.
#
# This paper proposes a lightweight, static annotation system called
# Discretionary Capability Confinement (DCC), which fully supports
# the adoption of abstract types as capability types and provably prevents
# capability theft and leakage.

This "leakage" is simply delegation. So if the system were to succeed in
its stated aim here (actually, I don't think it does), then it would be
enforcing a restriction that we don't want.

> In particular, is his "Heros and Sidekicks" game an interesting challenge 
> problem for language-based security?

To the extent that the problem is well-posed, it is solved by every
language-based object cap system since Gedanken and actors. I don't
know why the author considers it to be difficult, in a capability
language context.

# Two prototypical cheats are the following.
#
# Cheat I: Capability Theft. A Sidekick reference can be seen as a capability,
# the possession of which makes a Hero instance more potent. A malicious Hero
# can augment its own power by creating new instances of concrete Sidekicks,
# or stealing existing instances from unprotected sources, and then attaching
# these instances to itself.

A Hero should only have capabilities corresponding to powers that it should
have. What more is there to say about this? There only seems to be a problem
here if the language allows the Hero to create new instances of arbitrary
classes that may have ambient authority.

# Cheat II: Capability Theft and Leakage. A Hero exposes two type interfaces:
# (i) a sidekick management interface (i.e., Hero), and (ii) a state query
# interface (i.e., Observable). While the former is intended to be used
# exclusively by the GameEngine, the latter is a restrictive interface through
# which Heros may be accessed securely by Sidekicks.

This calls for a hero to have two facets.

# This means that a Hero reference is also a capability from the perspective
# of Sidekick. Upon receiving a Hero object through the Observable argument of
# the update method, a malicious Sidekick may downcast the Observable reference
# to a Hero reference, and thus exposes the sidekick management interface
# of the Hero object (i.e., capability theft).

Don't do that. Give the Sidekick only the facet it needs. Problem solved.

[If we look at the StatusHolder example from 'Concurrency Among Strangers',
we see that it already distinguishes between the held state, which in this
case would be the facet given to the Sidekick, and the holder, which would
be provided by (possibly inherited by) the Hero's management facet. Unlike
java.util.Observable, the object passed to each observer's update method
is not able to change the observer list.]


Now let's see how the author wants to solve it:

# Solution Approach. To control capability propagation, DCC assigns the
# Hero and Sidekick interfaces to two distinct confinement domains
# [21], and restricts the exchange of capability references between the
# two domains. Specifically, capability references may only cross confinement
# boundaries via explicit argument passing. Capability granting is thus
# possible only under conscious discretion.

Huh? In a pure object capability system, capability references can only be
transferred *at all* by explicit argument passing. There is no need to
specify static confinement domains in order to enforce that.

There may be a case for specifying static constraints as a check on design
intent; i.e. if we intend that objects of a given class do not escape some
specified context, then we may want to check that statically. I do not
believe that this should be part of the underlying access control system.
It does not need to be, and we should keep the access control rules as
simple as possible, as long as they are sufficiently expressive.

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