[cap-talk] What sustained interest in capabilities

[David-Sarah Hopwood]

David Wagner wrote:
> David Hopwood writes:
>> I don't find that this platitude tells me anything useful about how to
>> design systems.
> 
> It's not intended to.  What's intended to suggest is that there is not One
> Right Approach to the design of secure systems.  The best design usually
> depends upon context and on the requirements.

Hmm.

In what sense are any of the most successful computing platforms, such
as Windows, Unix, and C, themselves adapted to any particular context in
which they are used?

Computing is entirely dominated by general-purpose systems. If people
have a niche problem, do they use a niche *platform* to solve it? No,
they use a general-purpose platform (OS and language), perhaps adapted
in relatively minor ways by adding libraries supporting that niche.
At most, they use a language that is oriented toward, say, database
access or text manipulation, but that's about as specific as it gets --
and arguably any of those languages could adopt the features of the
others.

The idea of a capability system is an idea about how to structure
*general-purpose* computation in order to achieve security. That's
why most (essentially all) of the discussion on this list is about
general-purpose languages and operating systems. The design of a
capability system simply does not depend very much on what you're
going to do with it. The concepts are things like objects, references,
messages, etc., that are applicable to any domain, or at least to an
object-based way of modelling any domain.

I suppose you could say that "general-purpose programming language"
or "general-purpose consumer operating system" are particular contexts
with their own requirements. That may be technically true, but if so
then they're far more important contexts than any others, as far as
the long-term effect on the security of the computing infrastructure
is concerned.

(Of course there are some significant categories of system besides
these. For instance, real-time embedded operating systems are such a
category; their requirements are distinct enough that the implementations
of general-purpose consumer operating systems can't be used directly
without modification. Even so, the programming interfaces of almost
all real-time embedded OSes are based on Unix [or Windows in the case
of Windows-CE] to the extent that they can be.)

Sometimes a successful OS or language was originally designed for
a particular application domain. For example, Erlang was designed for
telecoms applications. But no language or OS can survive with a
healthy user base, if it *only* serves a particular domain. Erlang
is distinguished by good support for message-passing concurrency, which
was motivated by the applicability of that approach to telecoms.
However, it's otherwise completely general-purpose, and its concurrency
support is also general-purpose; it is not specialised to any noticeable
extent for telecoms.


The economic constraints imply that at any given time there will only
be a small number of widely used interfaces to which application programs
are written. To make a significant impact on computing infrastructure,
and on the security of that infrastructure, it's necessary to define one
of those interfaces. Whichever interface becomes most popular will define
the One Approach (or Small Number Of Approaches) that is used, whether
it is the Right approach or not.

So, if we are serious about improving the security of most computers
and networks, I think we'll have to essentially forget about producing
the best design for context and requirements, and instead produce
designs that can compete with the likes of Windows, Unix, and C in
terms of generality.

[again:]
> The best design usually depends upon context and on the requirements.

I'll be perfectly happy with a design that has strong security, and is
good enough at everything else. At the moment users are not given
the practical option of choosing a secure computing environment. I just
want to see them given that option.

[...]
> Of course it's no surprise that I believe there can be value in
> replacing one layer and everything above it with something based
> upon object-capabilities, even if the underlying layers are not.
> That's more or less how Joe-E works, for instance, and Joe-E is hardly
> unique is this respect.

Joe-E is consistent with the approach I'm advocating in this thread,
because it doesn't make any assumptions about what operating system
it is layered on: it works with any Java implementation, and the
design of Java doesn't make assumptions that would preclude it from
being implemented on, or even integrated with, a capability OS.

-- 
David-Sarah Hopwood ⚥