Insulating Environments

Some Proposed Terminology

In general an application lives in some environment. That environment has certain security properties. Security properties of an application are contingent on those of its environment. What we say of applications goes equally for other program modules. I have tried to define these terms so as to include non capability based systems. Others must judge if the definitions are biased.

These are sorts of protection that are feasible to provide by custom construction patterns, as the factory provides confinement.

I use the term “environment” for what may otherwise be called:

infrastructure
software platform
foundation
or TCB.

I propose four terms describing environments: veiling, confining, defending and isolating. Each of these describes a limitation of signals, or any cause on one side of the environment boundary, having an effect on the other side. We call these properties insulation collectively.

A veiling or confining environment limits outgoing signals. Defending and isolating environments limit incoming signals. Veiling and defending environments defer to the application within to communicate in the limited direction while confined and isolated environments impose their limitations regardless of application design. Together, veiling and defending amount to the encapsulation ideas of object design.
Kinds of Insulation
limit outgoing signals limit incoming signals
solicited, voluntary, keep bad guys out.
Gatekeeper inside. veil
An environment veils if the state of an application running in that environment cannot be sensed or obtained except as mediated by application logic. The application explicitly constructs any outgoing signals. defend
An environment defends if all signals from outside the environment are delivered to the application to be interpreted by explicit application logic. The application interprets all incoming signals.
imposed, involuntary, keep bad guys in.
Gatekeeper outside. confine
An environment confines if state in the environment cannot get out even with the coordinated efforts of code in and out of the environment. See factories.
Driver nooks confine device drivers not in order to keep secrets but to protect kernel integrity from driver actions.
isolate
The environment isolates if the state in the environment cannot be affected by events outside, even with the coordinated efforts of code in and out of the environment. See durability.

**Kinds of Insulation**
	limit outgoing signals	limit incoming signals
solicited, voluntary, keep bad guys out. Gatekeeper inside.	veil An environment veils if the state of an application running in that environment cannot be sensed or obtained except as mediated by application logic. The application explicitly constructs any outgoing signals.	defend An environment defends if all signals from outside the environment are delivered to the application to be interpreted by explicit application logic. The application interprets all incoming signals.
imposed, involuntary, keep bad guys in. Gatekeeper outside.	confine An environment confines if state in the environment cannot get out even with the coordinated efforts of code in and out of the environment. See factories. Driver nooks confine device drivers not in order to keep secrets but to protect kernel integrity from driver actions.	isolate The environment isolates if the state in the environment cannot be affected by events outside, even with the coordinated efforts of code in and out of the environment. See durability.

An environment may be for an individual invocation of the application, serial invocations, or concurrent invocations. The choice is external to the application. An isolated environment hosting an application for serial invocations would allow details of one invocation to influence the results of subsequent invocations.

We now discuss the degree to which the above insulation properties are needed and qualifying the degree to which they may be provided.

Just about any computer object needs a degree of defense. For an application to maintain integrity (keep working as it was designed) its environment must defend it. If someone logs into Unix with root access to install a debugger and, not recognizing a file that is in fact necessary for a mission critical application, deletes the file to make space, we would say that from this perspective the application’s environment failed to defend it.

For an application to keep secrets its environment must veil it as well. To this end it must also be defended to prevent its code from being supplanted by code that reveals the secrets, a risk that confined objects do not suffer! (There are usually additional reasons to defend confined objects).

Each of these insulation properties depends on the code that arranges for the insulation. In this context we will trust the factory and its infrastructure but the holes admitted by a factory makes the confinement it provides relative. Principled exemptions may also exist for a defending environment to provide for debugging the code therein for instance.

Just after you buy a new car or a new page from a KeyKos space bank you like to think that you have the only key to that car or page. That is indeed a useful fiction. In the case of the space bank the bank retains a copy of the key, in effect, in order to be able to reclaim its space when that bank is instructed to reclaim all of the space that it has allocated. But you had to trust the bank anyway if you need pages. If you should give the page key to an untrustworthy agent then you can no longer count the page as confined or veiled.

Another sort of exception to the pure properties described above is generally allowed to accommodate the instance owner. In factory theory a requestor invokes a factory which yields an instance in a confining environment. Typically the use of that instance will lead to capabilities within the instance to things outside the instance and confined environment. The nature of these capabilities is under control of the instance owner however. If we need a name for this situation we might try “Owner exemptions”.

We now examine factory logic in these terms. The factory proper resides in a defended environment. It is also veiled but that is not germane to its discretion properties, but it may be germane to the proprietary interests of its builder. The logic of the factory ensures that factory yields are confined, with an owner exemption for the requestor.

Respective Precluded Threats

Here are examples of breaches in Keykos terminology, that these respective insulations preclude:

Veil: A read-only page key resides somewhere outside the environment and the page holds state of the object within. It might be suitable for the object to explicitly export such a key; it is the existence of unknown such keys that veiling protects.
Defend: There is somewhere a domain service key to a domain within the environment. Invocation of this key can destroy the domain’s purpose.
Confine: There is a page and a RW key within the environment, and a RO key to the page outside. Code within can thereby pass data to a confederate outside.
Isolate: There is a page and a RO key within the environment, and a RW key to the page outside. Code within can thereby receive data from a confederate outside. For instance the code may get a signal from the code author that it is time to hold the object state for ransom, to be paid by the object owner to the code author.

Uses of isolating environments:

A program running in an isolating environment is incapable of being non deterministic.

Often it is possible to put a program to be debugged in such an environment. If the bug still occurs then it is possible to observe the steps leading up to the manifestation. Note that isolation does not preclude observation.
It may be strategic to re-run transaction code after a system crash with the logged inputs in order to regain its effects that were lost in the crash.
One can install an application such as a compiler so that it will do in the future what it would do today. See durability.
One might put a computation of PI in an isolated environment. No further input is needed after it is launched. Its isolation does not preclude pushing or pulling answers out.

In the compiler case some immutable defended object would be trusted to create an isolated compiler object. This latter would accept source and return object code. Subsequent invocations of the same compiler object might fail but a new object from the creator cannot fail.

Assurance of Insulation in Capability Systems

Why might we believe that some object is in an insulated environment?

In KeyKos the answer is usually by trusting the code that built the object, or at least launched its building. The object from the factory is known to be discreet because of the logic of the factory, which must be trusted to do as specified.

Objects (applications) in veiled or defended environments are in a position to ruin that insulation. The object must therefore be trusted to maintain that insulation.

But the natural design of objects in capability systems does just that. The minimal code to do a job almost certainly maintains the insulation. Ruining the insulation is not a common bug in code that defines objects. More complex objects go thru an early phase of building and may resume building as life goes on. A veiled environment remains so unless the building code exports capabilities to external objects. There is no reason to do this and it takes extra code. That is why it is unnatural.

Objects in environments that confine or isolate, on the other hand, are unable to ruin that sort of insulation. Once initiated in such an environment, subsequent building cannot cause it to fail.

A Means to an End

This section was stimulated by some useful annotations to this page by Jonathan Shapiro. He points out that it necessary to limit transmission of capabilities in order to ensure some forms of insulation. I agree. Indeed it is necessary to limit both the out-flow of in-pointing capabilities and the in-flow of out-pointing capabilities to provide involuntary insulation. Veiled and defended applications may choose to send and receive capabilities across the boundary however. Their logic must beware of incoming messages on exported keys and consider the security of the messages with which they invoke keys from the outside. Even a read-only page key may be exported by a voluntarily insulated application. In this case we indulge in the fiction that a read of the page is a message to the page which is handed by the kernel according to rules agreed upon by the application. This is like a read-only instance variable, readable and writable from inside the object but only readable from the outside.

The bottom line is that capability systems must limit authority flow in order to limit information flow. The end is limiting information flow. Limiting the flow of capabilities is a means to that end. This note does not describe all the means. Except for isolation, however, most descriptions may be found by following pointers.

cloud

Some Deeper Theory

Owner exemptions are vague so far. Here is a more rigorous explanation. Some earlier simpler more trusted program is the gatekeeper that establishes the insulating compartment. It will also mediate signals in the otherwise prohibited direction, for such are normally the purpose of the insulated program.

We will emphasize confining environments produced by factories but these ideas apply to other sorts of environments as well.

In general some computer activity is designed with partially conflicting goals. An employee data base application is supposed to provide facile access to employee information to some, while refusing that information to others, even others to which it must talk. An environment is produced for some purpose and some exec code, generally outside the environment, is in charge of that purpose. The exec code is responsible for certain security properties and achieves those ends by constructing the environment. The code running within the environment supports the purpose without itself being trustworthy for maintaining

This personnel application is responsible for security policy. To this end it establishes and maintains the following situation (or security invariant). The object O with the sensitive raw information (which is itself ignorant of any security issues) is in an environment E. Note that O may be a primitive such a segment or even a page, or may be a complex data base object; our argument is indifferent to that detail!