System Architecture

The goals of the CRISIS architecture can be described in two parts. First, users should be allowed secure access to global resources such as files, CPU cycles, or storage from anywhere in the world. Next, resource providers need mechanisms for authenticating those requesting their services and for authorizing those with the proper credentials. In this section, we provide a high-level view of the system architecture before detailing example usage in the next section.

In the following discussion, we assume the presence of three basic entities, adapted from the SRC logic [Lampson et al. 1991]:

• Principals: Principals are sources for requests. Examples of principals include users and machines. Principals make statements (requests, assertions etc.), have names, and can be associated with privileges.
• Objects: Objects are global system resources such as files, processors, printers, memory, etc.
• Reference Monitors: Once an access request from a principal to an object is authenticated, the reference monitor determines whether or not to grant the principal access to the object.

  

Figure 1: This figure describes a sample scenario where a user, P₁ requests a machine P₂ to run a job on its behalf. In turn P₂ sub-contracts a portion of the job to another machine P₃ in a separate administrative domain.

Consider the scenario where a user in California wishes to run a job at Texas which requires access to two input files. In turn, the job at Texas decides to subcontract a portion of its work to a machine in Washington. This sub-contracted work only needs access to the second input file. More formally, P₁ is a user in California, while P₂ and P₃ are machines willing to run jobs located at Texas and Washington respectively. O₁ and O₂ are objects (e.g. input files) located in California, with RM₁ and RM₂ their associated reference monitors. Assuming that P₁ (and only P₁) possesses access privileges to O₁ and O₂, consider the following sequence of events (summarized in Figure 1):

P₁ states that P₂ can access O₁ and O₂ until time T₁.
P₁ requests that P₂ execute a job on its behalf (steps 1 and 2).
P₂ requests access to O₁ from RM₁ (step 3).
P₂ states that P₃ can access O₂ until time T₂.
P₂ requests that P₃ execute a job on its behalf (steps 4 and 5).
P₃ requests access to O₂ from RM₂ (step 6).

To carry out the above scenario in WebOS, the security system must support:

• Statements: Statements may be requests, declarations of privileges, or transfer of privileges. The identity of the principal making a statement must be verified, and all statements must be revocable.
• Associating privileges with processes: While a particular machine may possess a large set of privileges, individual processes only have access to a subset of these privileges. Similarly, users may only wish to grant a subset of their available privileges to each of their programs.
• Distributing statements across the wide area: A protocol for trust between different administrative domains must be established to allow for validation of privileges and identities across administrative boundaries.
• Time: The transfer of privileges can only be valid for a limited period of time. CRISIS requires a clear protocol for reasoning about time, and a methodology for isolating failures in cases where clock skews lead to a security breach.
• Authorization: When a reference monitor receives a request to access an object, it must determine the identity of the requester, ascertain the principal's privileges, and finally decide whether the request is authorized.

Our solutions to each of the above are described in the following subsections.