Computer Security for the non Computer Specialist

While most material in these pages is for someone who builds software, this page is for a wider audience.

These pages are mostly about a style of hardware and software architecture that is unconventional yet has roots that go back to the early 60s. The style did not have mainly to do with security but merely seemed to some as the natural way of doing things. Indeed its favorable impact on security is only a recent emphasis.

The word usually used to conjure these notions is “capability”. These notions appear in a number of places and are familiar to many computer workers who know no name for such notions. Most programming languages have elements of capability style logic. Modern object programming languages have moved toward capability notions independently of classic capability ideas. The object capability model captures much of the capability paradigm in the context of programming languages. Alas languages sometimes compromise for efficiency or some misplaced notion of convenience and thus loose some capability benefits.

This page and this site is mainly about capability architectures for Operating systems (OSes).

As programs run they are aware of many ‘things’ in the computer system. To operate on these things they need some sort of token with which to denote them. In most current computers there are valid concerns that the many programs within the computer act on only those things they have legitimate access to. When a virus reads your e-mail it is an example of a program reading something it has no legitimate access to. The form of the rules that most OSes can apply is inadequate.

Today’s operating systems are able to host a variety of programs and apply rules as to which programs can act on which objects. The form of the rules is fixed by the operating system but the details of who can do which to what in particular is left to the programs to decide as the system runs.

The two sorts of OS architectures I distinguish here are (1) access list systems, and (2) capability systems.

access list
In these systems there is a rather static list of ‘users’ and each program is viewed by the system as an agent either of the user that caused the program to run, or of some particular specified user that installed the program. Things to be accessed have an associated access list that enumerate which users are allowed what sort of access. The identifying token is most often a string of characters which might identify any thing in the system.
capability
In these systems programs hold tokens, called capabilities, that they cannot counterfeit. Capabilities denote things to be accessed and are necessary to access them. Capabilities are passed among programs and a program gets a capability only when it arrives in a message.

I believe there are today no commercial capability OSes today. (2017 but see seL4!)

This page does not provide evidence that capability systems provide security. That is the topic of many pages at this site. This is perhaps the most concise claim for capability style hardware platforms. Our introductory page for capabilities does not assume much programming savvy. Here is a worthy attempt to describe capabilities to the non Computer Specialist.