[cap-talk] Understanding capabilities in a web-desktop setting

[David-Sarah Hopwood]

Ivan Krstić wrote:
> On Aug 5, 2008, at 4:54 AM, tsr wrote:
>> Now to what I think is m question how do I implement this in a
>> capabilities kind of way?
> 
> Let me turn this question back towards you: what problem do you have  
> with a traditional ACL-based authorization model that you think (or  
> hope, or wish) capabilities will solve for you in your system?
> 
> You appear to be saying "I've heard about capabilities, they sound  
> interesting, I want to use them for my system. Now, what are they and  
> how do I implement them?" Needless to say, this is a horrifically  
> backwards way to approach any kind of engineering, software or  
> otherwise, akin to saying "I've heard about Rolls Royce jumbo-jet  
> engines, they sound interesting, I want to use them for my bicycle.  
> Now, what are these jumbo-jet engines and how do I wire them to my  
> bicycle?"

If there were as active and vibrant a community of people building
capability systems as there is of people building home-made jet engines
and jet bikes [*], I'd be ecstatic. Seriously.


In any case, let me explain why I think this approach, even in the
exaggerated form in which you present it, is *not* backwards.

Progress in technical fields (arguably in any field) works by there
being lots of people in parallel, trying to combine the sets of
ideas that they have heard about or are interested in, in order
to come up with some new composition. The participants typically
start off with particular (often quite loose) goals, but their goals
can and often do change depending on what they are able to construct,
using the ideas and materials that they have available. That is,
although each individual composition is designed, the overall
activity is in some ways more closely analogous to evolution than
design.

In an environment where commercial pressures to finish a project on
budget and on time are dominant, then this approach may be considered
too inefficient. But as far as I can see, very little actual innovation
occurs in that kind of environment in which that view is prevalent.
Refinement of well-established ideas, yes, but not innovation.

(The distinction here is not really between "non-commercial" and
"commercial", it's between "speculative" research, and development
of concrete products. Xerox PARC was the canonical example of a
commercially sponsored environment that did valuable speculative
research. Such environments tend to get killed off by their sponsor
with high probability and in short order; PARC is one of the few that
survived long enough to invent and promote some useful stuff while it
lasted.)

Of course we do have concrete problems that we want to solve. One of
those problems is the prevalence of malware on end-user computers.
And we have lots of people trying to solve that problem using
approaches based on ACLs. Most, if not all, of them are failing badly.
Interestingly, *we know why that is*. We can give specific technical
and theoretical reasons why ACLs (and any mechanism that shares
particular properties with ACLs) lead to systems in which protection
domains are too coarse-grained, why they give the wrong answers
to some security decisions, and why their uses are bombarded with
confirmation prompts that they don't have the necessary information
to answer properly. (I'll expand on these points separately, or maybe
others on this list will want to expand on them.)

But those aren't the main reasons why I personally choose to work on
capability systems. I originally chose to work on capability systems
because:

  a) like a fair number of people on this list, I reinvented the
     basic idea;
  b) it is an idea that has been neglected over the course of
     40 years for reasons that have little to do with technical merit;
  c) most security researchers are working on other mechanisms [#].


Frankly, I can't see what harm it does if someone makes a decision about
what security mechanism(s) to work on that is initially fairly arbitrary.
If they are wrong, then they are only wasting their own time, not yours.
That's what all the people who develop ACL systems are doing -- it's
just that most of those people don't realise they're doing it, because
that is the only mechanism that they know about (or the only one that
they haven't rejected just because someone told them to).

One could make a strong case that if over the past 30 years each security
researcher had picked a potential security mechanism *totally at random*,
and devoted their research career to investigating the possibilities of
that mechanism (maybe combined with others), then we wouldn't be in the
malware hole that we are in at the moment. That hole is, I believe,
largely attributable to the narrow focus of security research and practice
on a tiny corner of the potential design space.

Since the original poster has only just started to learn about capabilities,
they aren't yet going to be able to make any kind of informed decision
about whether they are the "right" solution to any particular problem.
While it's possible to summarize the basic ideas behind capability systems
in a few words (combine authorization with designation; make references
unforgeable), the implications of doing those things at all levels of
the software stack take time to sink in. What the OP could do instead
is provisionally assume that capabilities are a solution that has some
chance of working, and learn whether that is actually the case by trying
to build a system based on them.

> An enumeration of the problems you're trying to solve and the security  
> properties you wish your system to have should be your first step. The  
> next should be finding the simplest solution which delivers those  
> properties.

That all sounds very reasonable and rational. The problem is, if everyone
does that, then only the approaches that superficially appear simple
end up being used, rather than the approaches that have a chance of
solving real-world security problems in the long-term, if it happens
that the latter don't initially look simple enough.

So, we have to try something different. Capabilities are different [+],
so let's try those.

In fact both capabilities and, say, ACLs are simple, but not in the same
sense:

  - A capability system enforces a very simple model of computation
    and authority propagation, but it takes some degree of familiarity
    with the associated design principles (called "capability discipline"
    on this list), in order to decide how to implement a given security
    policy. (This applies to programmers, mainly; not to end-users.)

  - ACL systems, and systems that are effectively special cases of ACLs
    like user/group/world permissions, *appear* to more directly enforce
    the security policies that people think that they want, but in fact
    end up introducing complexity as a result of not being able to
    enforce the policies that people actually need.

[+] Some people have attempted to argue that capability systems are
     really equivalent to ACL systems, but those arguments are
     technically flawed. Again, we know what the flaws are.

> Capabilities may be that solution, though they most often  
> aren't due to cumulative complexities of production systems.

"Most often aren't?"

As far as I can see, we do not have a large or diverse enough sample
of capability systems that have been put into production, to be able to
come to any conclusion about what their eventual cumulative complexity
"most often" is.

What we do know is that production systems using other security
mechanisms end up having *huge* cumulative complexity. I mean, ridiculous,
insupportable, unworkable, insane complexity -- to the extent that the
resulting reliability problems have given computers in general a bad
name among ordinary users. Even to the extent that many people see
unreliable and insecure computer systems as inevitable and have given
up on trying to solve those problems.

I'm not just talking about straw man examples like Windows, which are
complex also because of design errors that are not directly security-
related. Even systems that are much better designed in other respects,
end up having crippling security administration overhead that results
in the majority of users effectively not using the security mechanisms
at all.

There is an argument that the simplest approach that could potentially
provide adequate security is to build systems that can only enforce an
isolation policy between applications (or some approximation of an
isolation policy, where a single trusted component is permitted to
selectively breach isolation). That's a supportable argument, and don't
let anything I say here stop someone who wants to work on such systems
from doing so.

The reason I'm not working on such systems is that I don't think they
are expressive enough. Capability systems are certainly expressive
enough, and I don't know of any simpler way to obtain the degree of
security policy expressiveness that can be achieved by a capability
system.


[*] In the true spirit of innovation, there are many people learning
     how to build their own turbine engines (that are derived directly
     from the same technology as radial jet engines):

       <http://www.instructables.com/id/How-to-build-your-own-Jet-Engine/>
       <http://tech.groups.yahoo.com/group/DIYGasTurbines/>
       <http://www.pfranc.com/projects/turbine/top.htm>

     and, among other things, using them on motorcycles:

       <http://www.youtube.com/watch?v=ej-2VQPzdSc>

     and ordinary bicycles:

       <http://www.youtube.com/watch?v=vcVOE9XXnRg>

     More power to them.

[#] A scientist is scrabbling on their hands and knees in the dark of
     a dimly lit street, a long way from the nearest street lamp.
     "What are you doing?"
     "Looking for my keys."
     "If you looked for them under the street lamp, then if they are
      there, you'd be more likely to find them."
     "But everyone else who loses their keys does that, so it wouldn't
      be an interesting research approach."

     [If only this joke applied to security research.]

-- 
David-Sarah Hopwood