[cap-talk] A better reference for the "capabilities propagate too easily" argument

[David Hopwood]

Jed Donnelley wrote:
> The way I see the Horton work is that it is responding to one
> of the criticisms of object/capability computing that we saw
> in the various TCSEC criticisms, namely that it isn't possible
> to track/log/audit who was responsible for what with capabilities.
> Horton was a direct response to that criticism that came out
> of that paper.

(i.e. "Traditional Capability-Based Systems: An Analysis of their Ability
to Meet the Trusted Computer Security Evaluation Criteria")

> If we don't at least mention the criticism and the paper then why Horton?

No-one should care about that paper, and based on citations it appears that
hardly anyone does [*]. A much better paper to cite in this context is
Saltzer and Schroeder's "The Protection of Information in Computer Systems"
(1974, revised 1975), on-line at
<http://web.mit.edu/Saltzer/www/publications/protection/>.

>From section II.B
<http://web.mit.edu/Saltzer/www/publications/protection/Descriptors.html>:

# To gain more precise control of revocation, Redell [54] has proposed that
# the basic capability mechanism be extended to include the possibility of
# forcing a capability to specify its target indirectly through a second
# location before reaching the actual object of interest. [...]

(This is the caretaker pattern.)

# [...] While providing a systematic revocation strategy (if their user
# develops a protocol for systematically using them), the indirect objects
# provide only slight help for the problems of propagation and auditing.
#
# The basic trouble being encountered is that an authorization--a kind of
# binding--takes place any time a capability is copied. Unless an indirect
# object is created for the copy, there is no provision for reversing this
# binding. The ability to make a further copy (and potentially a new
# authorization) is coupled to possession of a capability and is not
# independently controllable. Restrictions on the ability to copy, while
# helping to limit the number or kind of authorizations, also hamper the
# simplicity, flexibility, and uniformity of capabilities as addresses.
# In particular, capabilities are especially useful as a way of
# communicating exactly the necessary arguments from one procedure to
# another. In this way, they encourage wide use of procedures, a cornerstone
# of good programming practice. Restrictions on copyability, then, inhibit
# their usefulness in the context of procedure calls, and that runs counter
# to the goal of providing base-level facilities that encourage good
# programming practice. This dilemma seems to present an opportunity for
# research. [...]

Indeed it does. IMO this is much more coherently and convincingly argued,
it puts both sides of the argument, and it appears in an earlier and more
historically influential [*] paper than the TCSEC one. It even suggests
the form of solution used by Horton (create indirect objects instead of
copying capabilities). The Horton paper doesn't currently cite Saltzer
and Schroeder, but it clearly should.

[*] The Saltzer and Schroeder paper has 194 citations on citeseer:
    <http://citeseer.ist.psu.edu/context/36634/0>, while the TCSEC paper
    has 1 self-citation by Gligor:
    <http://citeseer.ist.psu.edu/context/473051/0>.


Incidentally, this paper also gives a source for the term "wall-banging":

# Complete confinement of a program in a shared system is very difficult, or
# perhaps impossible, to accomplish, since the program may be able to signal
# to other users by strategies more subtle than writing into shared
# segments. For example, the program may intentionally vary its paging rate
# in a way users outside the compartment can observe, or it may simply stop,
# causing its user to go back to the original author for help, thereby
# revealing the fact that it stopped. D. Edwards characterized this problem
# with the phrase "banging on the walls."


A minor correction for the references of the Horton paper: the title of
Redell's PhD thesis is "Naming and Protection in Extendible Operating
Systems", not "Extensible" (or "Extendable" as some citations have it).
It is on-line at <http://www.lcs.mit.edu/publications/specpub.php?id=708>.

-- 
David Hopwood <david.hopwood at industrial-designers.co.uk>