It is often asked if capability functionality can be added to a conventional system such as Unix.
The facile answer is “no”.
The Evolution of Conventional Systems
The conventional way of adding function to a conventional operating system has been to increase the things that a program can do by either adding new system calls or new clauses under which some action is allowed.
(Contrast this with the evolution
of capability or OO style systems.) This seems be the meaning of “Upwards Compatibility”.
Arguments that my application is safe because unknown programs cannot damage me are thus made invalid as the system evolves and after the application design is done.
With this plan for adding new function it would seem that the natural evolution of a conventional system is towards less security.
I think that this is born out in practice.
It was a critical component of the problem with The Confused Deputy.
The imperative of a new OS release is to pass regression tests which demand that all of the old functions work.
I have never seen nor can I imagine tests that address inabilities of programs for in the Unix world there is no theory in which to express and reason about those inabilities.
The ideas that I have seen for adding capabilities to Unix are all subject to this pitfall.
They make old applications less secure and fail to add a niche for new secure applications.
Security stems from inability of programs, not from ability.
The above suggests that there are no design principles to guide the design of new Unix kernel functions.
This is not fair for there are things such as group IDs and user IDs that kernel primitives such as kill use to prevent random mayhem.
Such Unix features divide the world into a fixed set of too few parts which may not be dynamically arranged to suit the natural divisions of the application.
There is no central documentation of ways that signals can traverse the walls between these parts.
New system functions often punch new holes in these walls.
It is in this light that I am skeptical of the Mach 2.5 system which is a sort of amalgamation of Unix and capability function.
Perhaps there is a discipline there that supports security arguments but I have not noticed such a discipline described in the several Mach reports that I have looked at.
A system is not secure if the documentation does not teach secure design.
There are, nonetheless, useful projects that attain some useful combination of Unix (or other OS) and the new world of capabilities.
I have participated in the design of a few and have seen a few more such projects.
There are perhaps three types of melding: (Most of what I say about Unix applies as well to other systems.)
- Unix on top of a capability system
- Unix kernel function added to a capability kernel
- A capability platform as a Unix application
There may be several diverse goals in bringing capabilities to conventional systems.
Preservation of
- Applications
- Tools
- A familiar design environment
When we argue that some application within a capability system has some desirable property by virtue of being built within that system, those arguments are nearly always of the form:
| .
| Some class of programs that we cannot trust are unable to perform some deleterious action, because they lack any capability to do so.
|
We might not trust these programs because...
We may need to run these programs for their yield even if they are buggy
or malicious.
Problems with Capabilities Built upon Conventional Systems
There have been several attempts to implement environments matching those of conventional operating systems on top of capability systems.
A detailed description of the CP environment is referenced below.
Examples
Key Logic produced the CP Simulator which provided enough of the function of IBM’s CP component of their VM/370 as to run nearly all of IBM’s interactive development environment software.
On the 88K version of KeyKos, a Berkeley like Unix kernel was built sufficient to run a shell and X-Windows.
In this version many of the Unix objects were implemented as KeyKos objects.
The Unix “file” could thus be accessed by KeyKos programs that did not use the Unix facade.
The following lacks Focus and justification
A general problem with significant applications is that they occupy several address spaces and the logic of coordinating these components is complexand invests in those aspects of operating system design most at odds with capability design.
Programs that occupy one address space are often easily accommodated in a capability system.
Applications distributed between address spaces or even machines are often assembled with duct tape according to rules that are the source of the problems that capability design is meant to solve.
One way to ask if an application is suitable for migration to a capability architecture is whether there are more lines of compiled code, vs. shell scripts, Perl, Python, TCL etc.