Background

At this date {Jan 84} we have not yet taken steps to assure that the system's integrity is secure from the typical user. There tend to be keys in SYSTEM to vulnerable objects.

We now create the user's environment as a factory product. Only through the holes in that factory is the user able to impact the world beyond his environment. Only thru the same holes is the user able to expose his data.

There are at least these two problems with the current situation:

Even record collections with their "read-only" bit set are not manifestly immutable.

These record collections provide access to other mutable and vulnerable objects.

Our experience has so far been that there is not discipline sufficient to avoid installing new vulnerabilities to system integrity. Factories supply just this discipline.
Furthermore if a task of the TCB is to keep user A from signaling user B then user A must be unable to make any sensible change to objects shared with B.

One individual may work in more than one compartment. We shall say here that he has a "hat" per compartment. It is presumably satisfactory for security purposes for the system not to recognize the connection between these hats and to treat each hat as a separate user. This may be unsatisfactory to the individual.

We note that the system cannot prevent the user from transcribing what he sees on a TS screen to an unclassified keyboard. We note, however, that the system can manifest to the user the sensitivity of the objects he can see.

A window per hat would manifest just this information. If it is objectionable to include the window logic in the TCB then distinct terminals may be used in place of distinct windows.

We suppose a continuously growing set of compartmented users to whom we wish to make available a continuously growing set of facilities via keys.
We may sometimes wish to replace some of the facilities rather than add to them.

We wish to make these facilities available in a way so as to make the users invisible (thus guarding their secrets and protecting others from them). We judge that Gnosis factory logic is the appropriate technology to accomplish this.

The discretion of some of these facilities is not absolute (they have holes) and we thus need to withhold certain facilities from certain users.

We wish to avoid costs that are proportional to the product of the number of users and the number of facilities.

We have come to like the current tree structured directories of shared keys and have some code that expects them.

The users will each have a key to shared resources. The key will be shared and to a domain that obeys trusted code or to an unshared domain. We have no trusted code that acts as a record collection. We must therefore have individual domains that are designated by "SYS.". (The only out here is to abandon the fact that "SYS." and "FACS." name a record collections and adopt the idea at (as).)

Snap Shot Collections
Two variant types of name-sequenced record collections called MRC and SRC. An MRC is mutable and can produce a factory of SRC's. An SRC is immutable and provides access to the keys held by the MRC when the factory was produced.

If h is a hole of a factory produced by an MRC called m then either:

h is a hole of some factory whose requestor's key is held by m, or

h is a key held by m that is neither sensory nor a requestor's key.

The cost of the factory is roughly proportional to the amount of change to the MRC since the previous factory creation by that MRC. The cost of an SRC is small and does not depend on the size of the original MRC.

There is a call on the MRC that takes an SRC factory requestor's key and deletes that factory and all SRC's created therefrom and the space reserved for their support.

Implementation Details
The critical component of the SRC factory that makes this idea possible is the fetcher tree which models a state of a node tree imagined by the logic of the RC {B-trees}.

Three new constructs underlie MRC's and SRC's: f-nodes, fetcher trees and c-trees. The f-node {fake node} is an object that behaves sufficiently like a node to suit RC logic. The MRC composes f-nodes into mutable trees just as RC composes nodes into mutable trees. A fetcher tree forms an immutable model of a state of such a tree of f-nodes. There is a distinct factory creator that is used just to create the factories of these fetcher trees. A c-tree administrates a fetcher tree in a manner described below.

The MRC factory uses a fake spacebank that produces real pages and f-nodes. The f-nodes obey order codes 0 thru 31 (fetch and store). These are the only codes used by a record collection in its normal function except for the first three nodes (which will be real) bought as the collection is created.

These fetcher trees share sub-trees. For each fetcher tree T (including subtrees) there is a c-tree which is composed of a node holding: a fetcher key to T, a reference count and a node key to a node holding c-tree keys to the respective subtrees of T. The reference count indicates how many fetcher trees T is shared by.

The f-node obeys an order "dup" which yields access to a c-tree governing a fetcher tree that models the f-node. An f-node keeps access to the c-tree when it yields such (the "kept c-tree"). An f-node F obeys the dup order by issuing the dup order to each of the 16 keys that F holds if they are f-node keys. If each of the resulting c-trees are the same c-tree as the c-tree keys in F's kept c-tree (if any) then the kept tree is used and no new c-tree or new factory is produced. Otherwise a new factory and c-tree is required.

F-nodes are created and deleted as the corresponding real nodes would be. When a fake factory is called upon to delete an f-node, the f-node is notified so as to take appropriate actions.

When an SRC factory is desired, the record collection invokes a dup code on the f-node that represents the top node of the MRC's state. This code yields a fetcher tree that matches the current state of the MRC. The root of this tree is placed as a component in a new factory whose domain creator is unique to the code of the MRC. The MRC delivers the requestor's key in the reply. Yields of this factory can produce the keys at the leaves of the fetcher tree.

A further modification to the SRC logic would preserve data abstraction. A domain u, obeying the SRC code, would take the requestor's key to an SRC factory S, obtain the fetcher key to S with the "recall fetcher key" order code to S's creator (to which u holds a key with recall-fetcher-rights) and extract and use the state component from S. This would avoid the 50 ms required to build a new SRC and hopefully be much quicker. This strategy might be significant for the registry in evaluating "SYS.ZOT.", which would, in this case, be a SRC factory.

Alan's scheme

Alan thinks we should modify the registry to accept as the yield of names such as "FACS." a fetcher factory whose component 0 is a read-only-no-call memory key to a segment holding names of keys to be found in the rest of a fetcher factory tree rooted here.

See (p2,dd) for initial ideas on a diode directory.

An objection to this scheme is that programs (other than the registry) that fetch the key called "FACS." will expect a record collection key.

The registry could produce a key value for "FACS." that would behave as a record collection, but it is a difficult management problem to know when to create and delete the objects referred to by such keys. Value objects {(p2,vo)} might solve this problem but we haven invented them yet.