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:
A veiling or confining environment limits outgoing signals. Defending and isolating environments limit incoming signals. Veiling and defending environments allow 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.
|limit outgoing signals||limit incoming signals|
|solicited, voluntary, keep bad guys out.
An environment veils if the state of an application running in that environment cannot be sensed or obtained except as mediated by the application. The application explicitly constructs any outgoing signals.
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.
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.
The environment isolates if the state in the environment cannot be effected 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.
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.
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.
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.
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!