[cap-talk] Horton at HotSec '07: How broadly object/capability?
jed at nersc.gov
Tue Jul 10 21:11:18 EDT 2007
Karp, Alan H wrote:
> Shap wrote:
>>>> Alan: HotSec is being modeled after HotNets and HotOS.
>> The audience
>>>> definitely will NOT consist of the great unwashed.
>>> Not unwashed in the OS tub, just in the capability shower.
>> Um. You might be surprised.
> I would be. Based on my experience at the latest Usenix conference,
> even the few people who were familiar with capabilities had serious
> misconceptions about them.
>> Since space is very limited, rework the intro first and then see where
>> you are. Just a suggestion, but I find that seeing it on the page is
>> different than knowing it in my head.
> I agree.
I can appreciate the wisdom of this approach. In thinking about this a
bit I'm starting
on an approach that I believe may be complimentary - namely starting work on
a presentation (mostly putting the Horton work into the general computing
context), thinking we can then see how much of such a presentation might
be appropriate for trying to integrate into the paper (e.g. the
I started working on this approach and just let it flow below. I'm not sure
where to go with it at this point (maybe the start of another paper?), but
I include it below for your possible interest/comment - on the way to
putting together a presentation suitable for the Horton discussion
I believe it's appropriate to start very briefly at the highest possible
Computers are a wonderful invention. They are very inexpensive little
slaves (with none of the ethical issues normally associated with slaves -
at least yet) that can do our bidding. To do so they must run programs
that people write. We now have this wonderful collection of people
who are writing all sorts of useful programs.
However, the computer user community and market is currently
consumed by FEAR and LOATHING:
We are LOATHE to run programs that we may find (e.g. directly on
our systems or incorporated with other pieces of software - e.g.
like plugins) because we are AFRAID of what such software
may do to our systems. Public enemy #1 in this situation amounts
to Microsoft's (bogus) first 'immutable' law of computer security:
Law #1: If a bad guy can persuade you to run his program on your
computer, it's not your computer anymore.
Running a program on our computers today is analogous to
letting the programmer into our home while we are away.
The programmer has carte blanche access to everything we
have access to on our system. When I run a program on my
system I generally have no choice but to run the program
as myself as a 'user' - with my own authority.
How did we get into this situation, why do we seem so firmly
entrenched in it, and what hope do we have of improving it?
I'm to some extent a relic of an era when we weren't entrenched
in this situation, when we spoke confidently about mutually
suspicious processes, the Principle Of Least Privilege
(now usually more carefully referred to as the Principle Of
Least Authority, POLA), and when we designed and
implemented systems with these properties, often referred
to as "capability" based systems. These systems were
really object based and were distinguished by the simple
facility to communicate access permissions as tokens
that were essentially object reference parameters. In
such systems one can start with zero based access
control (vs. 'user' based) and communicate any needed
permissions to programs when they are run.
Seems easy enough, right? We know now that it's not
particularly easy. There are issues in defining which
permissions any given program should have to begin
with (initialization) and how to communicate permissions
dynamically as needed to running programs (often
referred to these days as "power box"es). As we now
know, these issues, while not particularly easy, are
subject to quite simple and straight forward implementation
work and in fact need not even significantly impact user
People have often expressed concern about some
necessary inefficiency and complexity in dealing
with so many individual object references. We now
know that doing so constitutes simple object oriented
programming and need not be either inefficient nor
complex. In fact the complexity (and to some extent
the efficiency follows) is reduced because we deal
with a simple paradigm of always communicated
exactly the needed parameters across all our
What really happened in the late 1980s when all
our proud and hopeful least privilege notions finally
disappeared into a uniformity of 'user' based access
I decided to look back at this period, the time of the
"Orange Book" and many security focused efforts to
see if I could figure out what happened. Of course
one aspect of things was that in that pre Internet era,
concerns about Trojan horses were somewhat abstract
and not particularly focused. Still, all else being equal,
why didn't the people at the time focusing on computer
security push toward the least access model?
I chose to focus particular attention on this document:
Traditional Capability-Based Systems: An Analysis of
Their Ability to Meet the Trusted Computer Security
Evaluation Criteria - a scan of which can now be
If you read through this document, the answer becomes
abundantly clear. They argued that systems with
communicable object references (capabilities) were
inadequate to meet their security criteria because
they were afraid - very afraid. They were afraid of
loss of control.
From their viewpoint object/capability communication
is "uncontrolled" and dangerous. That is, it isn't subject
to constraints such as MACs, auditing, etc.
In reading this document carefully (my detailed comments
on it can be found in the archive for this list at:
and in follow-on discussion such as:
) I found that this fear basically resulted from three factors:
A. Fear of delegation of permissions in violation of what could
otherwise be enforced policies,
B. Fear of an inability to enforce multilevel security MAC mechanisms, and
C. Fear that with capability permission tokens being passed around
it would be impossible to provide log/audit information about who
(what person) was responsible for which actions.
Before addressing these in detail I should note that the goal to be
achieved is the enabling of cooperation between people and
programs running as our slaves on our behalf. We emphatically
do not want to block collaboration (except in so far as we wish
to block communication - a relatively rare situation), but rather
we wish to support collaboration within appropriate (we hope
POLA) constraints. This fact often seems to sort of get lost
in security discussions where it almost seems like the only
real solution is pulling the plug. What we want to be able to
do is to enable collaboration without forcing people to essentially
share identities (e.g. share passwords).
A. What this fear of delegation seems to come down to
is what we've called the "cooperating conspirators" problem.
If two running programs are able to communicate, then no
amount of access controls are going to stop them from
collaborating, including any shared object access. User
based ACL systems can't stop such collaboration, capability
systems can't stop such collaboration. The only way to
stop such collaboration is to stop the communication - i.e.
By including the permission to communication to exactly
the needed server of an object with the bundled naming
of the object and permission to access the object,
object/capability communication of access tokens
allows exactly the needed amount of communication
for collaboration. If A has no capability enabling
communication to B, then A can't share another
capability with B. This is the most that can be achieved.
Object/capability systems allow POLA control over such
communication just as they do for all access and so can
do a much better job of blocking delegations that one might
want to block by policy than any user based ACL scheme.
B. The multilevel security and Mandatory Access Control
issues have been addressed elsewhere. I'll just note here
that again object/capability system can manage such policies
better than user based ACL mechanisms.
C. The final issue, that of identifying parties responsible
for actions and logging is the one that we addressed in
the Horton paper. There we show that the notion of identities
and tracking responsibility for object/capability (token) mediated
actions (including delegations) by identity can indeed
be done in object/capability systems.
It's in this sense that we feel that the demonstration of
the Horton mechanism removes the final technical barrier
to using the object/capability paradigm generally to
enable collaboration between people and between running
programs on our little slaves.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cap-talk