[cap-talk] What sustained interest in capabilities

[David-Sarah Hopwood]

David Wagner wrote:
> Mitsu Hadeishi <mitsu at syntheticzero.com> writes:
>> In other words, what I am saying is that using capability security  
>> today, now, can be done in practical, usable systems which allows a  
>> huge class of risks to be eliminated.  The point is this is *extremely  
>> useful*.  It is not that it completely eliminates all risk.
> 
> I agree 100%.  A system might not be perfect, but if it is
> useful, great!
> 
> Put another way, systems security is often about tradeoffs: e.g.,
> tradeoffs between the level of assurance you want vs cost (or other
> considerations).

I don't find that this platitude tells me anything useful about how to
design systems. This is not directed at you in particular, David, but my
experience is that people who use this argument are often too complacent
about accepting an existing perception of where the tradeoff curve lies.
It's certainly true that existing security architectures accept huge costs,
without obtaining much security. My inclination would always be toward
attempting to use new ideas (or old but neglected ideas) to change the
shape of the curve.

In any case, lumping all costs together is not helpful:

For instance, I believe that in order to achieve adequately high
assurance, it will be necessary to accept relatively high backward
compatibility costs -- specifically, that we abandon ABI compatibility
and concentrate on other forms of compatibility with existing systems.
Enough software is distributed in source form now, to make it practical
to require recompilation.

On the other hand, we cannot accept significant usability costs; if
anything, usability must be better with capability systems than with
ACL systems, if the former are to have any chance of adoption.

I'll state that more strongly: if we cannot both substantially
increase security assurance and at the same time reduce usability
costs relative to existing systems, then we might as well pack this
in and go home. I do believe that it is possible to achieve that.

Performance costs also matter, but mainly to the extent that
perceived performance overhead can lead people to employ designs in
which protection domains are too coarse-grained. In any case,
capability systems are in principle able to achieve adequately high
performance without compromising on security goals and assurance.

> I think [David-Sarah] Hopwood's argument may make
> sense where assurance is paramount and takes precedence over other
> considerations,

When is this not true of a security system, if we want the system
to actually be secure against competent attackers?

The level of assurance we have from most existing systems is pathetic.
Attackers don't even have to try very hard. Users do not currently
have the choice of using really high-assurance systems, because they
do not exist.

Computer systems can't be meaningfully separated into those that need
high assurance and those that don't, because it is demonstrably the
case that people end up:

 - storing high-assurance data on whatever system is the most
   commonly used.
 - repurposing systems that started out as low-assurance for
   high-assurance uses.
 - networking low-assurance systems with high-assurance ones, and then
   using inadequate mechanisms such as firewalls to separate them.

> but I think it's also interesting to look at other
> points in the tradeoff space.
> 
> Put yet another way, I think there's room in this town for both
> approaches: both for hard-core, no-compromises, security-is-everything
> ground-up re-design of all layers, as well as approaches that replace only
> a subset of the layers and may be imperfect but are useful and deployable.

Clearly I haven't succeeded in communicating the approach that I was
advocating. I'll try again:

 - Each interface between layers should be co-designed to optimise its
   ability to satisfy the requirements of the neighboring layers (see
   examples below).

 - Each layer should be deployed as soon as it is implemented.

 - It should not be assumed that replacing any proper subset of layers
   will achieve all of the benefits that are in principle available
   from capabilities.

 - Each layer should be designed with security taking precedence over
   compatibility. If a compatibility shim is needed to allow short-term
   deployment of the layer, then it should be something that is designed
   to be thrown away at a later date -- that is, not essential to the
   layer's external interfaces.

 - All the layers should eventually be replaced.

This is not a "no-compromises" approach. A no-compromises approach would
be attempting to perform a simultaneous global optimization of all of
the layers. I don't think that is practical, so what I'm suggesting is
to co-design layers (especially neighbouring layers), without requiring
them to be deployed together. This is "hard-core", "security-is-everything",
and eventually leads to a ground-up re-design, but is also useful and
incrementally deployable.

It is also substantially different from what Mitsui was arguing for.
He was arguing that adequate assurance can be obtained by building
single capability layers in isolation, regardless of what interface
they are layered on top of, and without using co-design. I believe
that's wrong (and I'm not going to water down my position on this just
for the sake of harmony and concensus).

Examples of the kind of co-design between layers that I'm advocating
would include:

 - designing multiple layers to be able to use the same instantiation of
   a neighbouring layer, for example,

    * compiling multiple high-level capability secure languages to the
      same capability-secure intermediate language,
    * linking different local capability systems using a common
      distributed capability protocol.

 - designing the values and type systems at different layers (including
   alternative layer instantiations at the same level) to minimize the
   need for interconversion.

 - using consistent and non-conflicting terminology to describe concepts.

 - reusing file formats and protocols between layers.

 - reusing theoretical work on formal models, type and auditing systems,
   security analysis techniques and tools, design and architectural
   patterns, etc.

 - implementing layers using common capability-secure languages.

 - sharing marketing efforts, and packaging different capability-based
   systems together whenever that makes sense.

> Both kinds of work are valuable and should be welcomed and encouraged.
> Let a million flowers bloom.

If we had unlimited resources (in particular, an unlimited number of
enthusiatic people advocating capabilities), we could let a million
flowers bloom.

But we don't, so at some point (perhaps not yet), it is going to be
necessary to concentrate effort on a relatively small number of layer
and interface designs -- just as our competitors have done.

-- 
David-Sarah Hopwood ⚥