How do capabilities bear on computer security?

(or why security isn’t grungy in capability systems)

POLA = Principle of Least Authority.
In a capability based computing environment, a piece of code just naturally has authority to only those things its needs to do its job. Extra design for security is not generally required.

By contrast Unix and other non capability based systems, protect computing objects, but only with coarse grained and static access rules. Extra effort is required to control this apparatus for particular security requirements of the application. Over permissive blunders in this effort are not likely to be caught in testing for most testing is of benign usage. These rules are enforced by a large, complex and monolithic set of code that is not user replaceable and these rules are not not well suited for defining new security functions.

These things are wrong with access lists and category permissions:

The rules for setting these limits are themselves flawed and preclude solving a list of security problems.
They require unnecessary extra steps in the design and establishment of a new computing service.
They are not fail-safe—the consequences of making them too permissive is most likely discovered only after a penetration, and possibly not even then.
Being coarse and static, these protections are too permissive.

Code to install an application frequently runs with the authority (root) to destroy other applications, or indeed destroy the entire system.

Applications have no domain within which they have the means to insure their own integrity. If the hardware is shared, they are at risk from other applications. The second order effect is that program builders may not aspire to truly reliable service since other apps provide a ready excuse for failure; and should they succeed in producing a perfect design and perfect code, they would seldom get credit, since their application would still be perceived as flaky as other apps transgress. It is a tragedy of the commons. In short, the incentives for solid code are badly weakened, and the possibility of solid applications is almost destroyed.

Kindred Rhetoric

Relevant point not yet assimilated:

Much security benefit would come from limiting legacy applications to the authority necessary for their function. Legacy applications are mostly written in languages that are prone to indeterminate semantics in extreme cases: C, C++. (They are not even guaranteed to die in the extreme cases.)