• TABLE OF CONTENTS
HIDE
 Title Page
 Table of Contents
 Abstract
 Main
 Appendix






Group Title: Department of Computer and Information Science and Engineering Technical Reports
Title: The Distributed compartment model for resource management and access control
CITATION PDF VIEWER THUMBNAILS PAGE IMAGE
Full Citation
STANDARD VIEW MARC VIEW
Permanent Link: http://ufdc.ufl.edu/UF00095304/00001
 Material Information
Title: The Distributed compartment model for resource management and access control
Series Title: Department of Computer and Information Science and Engineering Technical Report ; 94-035
Physical Description: Book
Language: English
Creator: Greenwald, Steven J.
Newman-Wolfe, Richard E.
Publisher: Department of Computer and Information Sciences, University of Florida
Place of Publication: Gainesville, Fla.
Publication Date: October, 1994
Copyright Date: 1994
 Record Information
Bibliographic ID: UF00095304
Volume ID: VID00001
Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.

Downloads

This item has the following downloads:

1994156 ( PDF )


Table of Contents
    Title Page
        Title Page
    Table of Contents
        Page 1
        Page 2
        Page 3
        Page 4
    Abstract
        Page 5
    Main
        Page 1
        Page 2
        Page 3
        Page 4
        Page 5
        Page 6
        Page 7
        Page 8
        Page 9
        Page 10
        Page 11
        Page 12
        Page 13
        Page 14
        Page 15
        Page 16
        Page 17
        Page 18
        Page 19
        Page 20
        Page 21
        Page 22
        Page 23
        Page 24
        Page 25
        Page 26
        Page 27
        Page 28
        Page 29
        Page 30
        Page 31
        Page 32
        Page 33
        Page 34
        Page 35
        Page 36
        Page 37
        Page 38
        Page 39
        Page 40
        Page 41
        Page 42
        Page 43
        Page 44
        Page 45
        Page 46
        Page 47
        Page 48
        Page 49
        Page 50
        Page 51
        Page 52
        Page 53
        Page 54
        Page 55
        Page 56
        Page 57
        Page 58
        Page 59
        Page 60
        Page 61
        Page 62
        Page 63
        Page 64
        Page 65
        Page 66
        Page 67
        Page 68
        Page 69
        Page 70
        Page 71
        Page 72
        Page 73
        Page 74
        Page 75
        Page 76
        Page 77
        Page 78
        Page 79
        Page 80
        Page 81
        Page 82
        Page 83
        Page 84
        Page 85
        Page 86
        Page 87
        Page 88
        Page 89
        Page 90
        Page 91
        Page 92
        Page 93
    Appendix
        Page 94
        Page 95
        Page 96
        Page 97
        Page 98
        Page 99
        Page 100
        Page 101
        Page 102
        Page 103
Full Text















The Distributed Compartment
Model for Resource Management
and Access Control


Steven J. Greenwald (sjg@cis.ufl.edu)
and
Richard E. Newman-Wolfe (nemo@cis.ufl.edu)

Technical Report Number TR94-035
Department of Computer and Information Sciences
The University of Florida
Gainesville, Florida 32611


October, 1994
















Contents




KEY TO SYMBOLS 3

Abstract 4

1 INTRODUCTION 1
1.1 Overview . . . . . . . . . . . . . .. . . . . . 1
1.2 D efinitions . . . . . . . . . . . . . . . . . . 1
1.3 Problem Statement .................. . . ... 2
1.3.1 Introduction ................... ........... 2
1.3.2 Security Problems with Distributed Systems .. . . . . . 2
1.3.3 Comments ................... . . . . . ... 4
1.4 Technical Report Organization. .................. . . .. 4

2 SURVEY OF RELEVANT WORK 5
2.1 Introduction ................... . . . . . .. 5
2.2 Access Matrix Model .................. . . ... 5
2.2.1 Introduction .................. . . . . . ... 5
2.2.2 Description .................. . . ... 5
2.2.3 Comments ................... . . . . . ... 6
2.3 The Bell-LaPadula model . ............... . . .... 6
2.3.1 Introduction .............. . . . . ... 6
2.3.2 Military Message Experiment ................ . .. 8
2.3.3 Air Force Data Services Center Multics ...... . . . . . 9
2.3.4 Kernelized Secure Operating System ..... . . . . .... 9
2.3.5 Guard ................... ............... 9
2.3.6 Comments ................... . . . . . ... 9
2.4 Other Information Flow Models .................. ..... 10
2.4.1 Introduction .................. ............. 10
2.4.2 Description .................. ............. 10
2.4.3 Com m ents .................. .............. 11
2.5 Military Message System .................. .......... 11
2.5.1 Introduction .................. ............. 11
2.5.2 Description . .. ... .. .. .. .. ... . .. .. .. ...... 11
2.5.3 Com m ents .................. .............. 13
2.6 Andrew .................. ................... 13









2.6.1 Introduction .................. ............. 13
2.6.2 Description .................. ............. 13
2.6.3 Com m ents .................. .............. 14
2.7 The ADMIRAL Model .................. ........... 15
2.7.1 Introduction .................. ............. 15
2.7.2 Description .................. ............. 15
2.7.3 Com m ents .................. .............. 17
2.8 IX ................... .. ........ ...... . . 17
2.8.1 Introduction .................. ............. 17
2.8.2 Description .................. ............. 17
2.8.3 Com m ents .................. .............. 18
2.9 Am oeba .................. ................... 18
2.9.1 Introduction .................. ............. 18
2.9.2 Description .................. ............. 18
2.9.3 Com m ents .................. .............. 18
2.10 Other Work ................... ............... .. 19
2.11 Conclusions . .. .. .. ... .. .. .. .. ... .. .. .. .. ...... 19

3 THE DISTRIBUTED COMPARTMENT MODEL PHILOSOPHY 20
3.1 Introduction . .. .. .. ... .. .. .. .. ... .. .. .. .. ...... 20
3.2 Distributed Handles .................. ............. 21
3.3 Distributed Compartments .................. ......... 22
3.4 Conclusions . .. .. .. ... .. .. .. .. ... .. .. .. .. ...... 25

4 THE DISTRIBUTED COMPARTMENT MODEL 26
4.1 Introduction .................. ................. 26
4.2 The Standard Model .................. ............ 27
4.2.1 Components .................. ............. 27
4.2.2 Secure State Invariants .................. ....... 37
4.2.3 The Rules of Operation .................. .... . 39
4.3 Aftermath .................. .................. 77

5 DISCUSSION OF THE DISTRIBUTED COMPARTMENT MODEL 78
5.1 Introduction .................. .......... ...... 78
5.2 Comparison of the Distributed Compartment Model to BLP . . . ... 78
5.2.1 Introduction .................. ............. 78
5.2.2 Sim ilarities . .. ... .. .. .. .. ... . .. .. .. ...... 78
5.2.3 Differences. .................. ............. 79
5.2.4 Conclusions . . . . . . ....... . . . . . 79
5.3 Alternatives to the Standard Distributed Compartment Model . . ... 80
5.3.1 Introduction .................. ............. 80
5.3.2 Second M odel .................. ............ 80
5.3.3 Third M odel .................. ............. 81
5.3.4 Fourth M odel .................. ............ 82
5.3.5 Fifth M odel .................. ............. 82









5.3.6 Conclusions ..................... . . . . 82
5.4 Implementation Issues .................. ........... 83
5.4.1 Introduction .................. ............. 83
5.4.2 Software Design .................. ........... 83
5.4.3 Software Implementation .................. .... . 84
5.5 Usage Examples ................... . . . . ..... 84
5.5.1 Electronic Mail Between Discoms ................. . i
5.5.2 "Simple" File Creation .................. ....... . .
5.5.3 "Com pl. :: File Creation .................. .... . i
5.5.4 Replicated Fault Tolerant Files ............... . .. . i
5.5.5 CPU Resource Access .................. ....... . i
5.5.6 Distributed Conferencing .................. .... . .
5.5.7 Grading Projects .................. .......... .
5.5.8 Paper Collaboration .................. ........ 87
5.5.9 Location Transparency .................. ....... 88
5.6 Future Research .................. ............... 88
5.7 Conclusions . .. .. .. ... .. .. .. .. ... .. .. .. .. ...... 89

6 CONCLUSIONS 91
Acknowledgements .................. ................ 92

A MATHEMATICAL NOMENCLATURE 94
A.1 Set Notation . . ............... ............. . 94
A .2 Relations . . .. . . . . . . . .. . . . . . . . 94

B AN OVERVIEW OF THE BELL-LAPADULA MODEL 96
B.1 Introduction .................. ................. 96
B.2 Overview ....... . ............ ....... ..... 97
B.2.1 Descriptive Capability . ............... ....... 97
B.2.2 General Mechanisms .................. ........ 99
B.2.3 Specific Solutions .................. .......... 99
B.3 Conclusion .. .. .. . . . . . . .... . . . . . . .99

REFERENCES 99









KEY TO SYMBOLS


Symbol Description
S such that
iff if and only if
= then, implies
A logical and
V logical or
logical not
U union
n intersection
0 empty set
V for all, the universal quantifier
3 there exists some, the existential quantifier
/3 there does not exist some
E is an element of the referenced set
S is not an element of the referenced set
C contained in or equal to, subset
not contained in or equal to, not a subset
C contained in but not equal to, proper subset
S maps
S maps to, for the element of a set
S maps to, for a set
Iin projection: returns the nth element of a tuple
governs
4, sires
I+ rules
N, ra-accesses
p, rn-requests
T, T Rule set, element of a rule set
T usage function (for a resource)
a designates an unused, sanitized resource
designates an unused, unsanitized resource
A discom function (for a resource)



















Abstract


Given the present trends regarding distributed computer systems, the standard model
of security used on most distributed systems is outmoded. This older model dates back to
simpler times and is based on the idea of a centrally managed system (usually a mainframe or
minicomputer system). Even modern networked computer environments are usually centrally
managed systems using this older model.
This older model is based on the idea that there is a central managing authority, called
the system administration, that is ultimately responsible for the management of computer
security. This management is usually done with some form of a discretionary access control
method, where each user is granted (or denied) privileges and resources depending on the
security policies enforced at that particular system. The system administration, among other
things, manages the system resources, creates and destroys user accounts, and grants and
revokes user privileges. This model is typified by an operating system such as UNIX.
This model introduces several difficulties when working in a distributed computing envi-
ronment. The scope of this technical report is in the problem areas of resource management
and access control. The solution proposed herein is a "Distributed Compartment" model
consisting of two major components. First, "Distributed Handles" are a method for user
identification and access control. Second, "Distributed Compartments" are a method for
allowing users to manage resources within a distributed system across computer system ad-
ministrative boundaries without many of the restraints of the old model. A formal security
model is presented that defines these concepts, and further refines them into a state transition
model.
The formal axiomatic model presented consists of component sets and their members.
There is a set of binary relations used to partially order the sets and specify operations on
sets. The model defines a secure system state and rules of operation provide secure state
transitions from one secure system state to another. There is a set of secure system state
invariants that each rule must satisfy in order to maintain a secure system state. Each rule
is proven secure within the model.














Chapter 1


INTRODUCTION



1.1 Overview

The security model currently used on most distributed systems is an old one, dating back
to simpler times when most computer systems were centralized. This model is based on
the idea that there is a central managing authority, called the si', ,i administration, that
is ultimately responsible for the management of computer security [34]. In this model,
the system administration, among other things, manages the system resources, creates and
destroys user accounts, and grants and revokes user privileges. This model is typified by an
operating system such as UNIX [2].
This model introduces some difficulties when working in a distributed computing environ-
ment. The solution proposed here is a new model consisting of two components: distributed
handles and distributed compartments. This new model, the Distributed Compartment Model
[18] is a new paradigm for the management of resources and the controlling of user access on
distributed computer systems. The Distributed Compartment Model was specifically created
to rectify some of the problems and deficiencies of the current models of access control [13].
It is our hope that the Distributed Compartment Model will be implemented in a dis-
tributed computing system environment, such as a UNIX based distributed computer system.


1.2 Definitions

The following definitions are provided to help characterize the problem. In general, they
correspond to their usual meaning in the computing community. There may be considerable
overlap between some of the definitions and those defined elsewhere, such as at the National
Computer Security Center [30].

Computer System This is a collection of one or more computers and their software that
is managed as a discrete unit. A particular computer system being used may also be
referred to as a host.

HostID This is a unique identifier for a computer system.









System Administration This is the agent responsible for maintaining a particular com-
puter system. That computer system may be composed of just one computer, or
may be a network of computers. For the purposes of this technical report the system
administration is the supreme authority for a computer system.

User This is a discrete entity, usually human, that uses computing resources. Users are
atomic (i.e., they may not be subdivided).

UserID This is an operating system dependent user identification label. This is a well-
known concept in operating systems. Under a typical operating system, the system
administration must manage userIDs in a centralized fashion. Any requests for new
userlDs must be made to the system administration.

Password This is a string that a user must provide at login time in order to authenticate a
userID and gain access to a computer system. In certain cases this string may be null
(i.e., no password is needed for access).

Standard Access Control Model (SACM) This is a common method of computer sys-
tem access control, consisting of users who are each provided by the system administra-
tion with a unique userID, and who require a password to gain access to the computer
system.

Distributed System This is a collection of computer systems that can communicate with
each other. A distributed system may be managed by different system administrations.

Distributed Collaboration This is work performed by more than one user using a dis-
tributed system.

Groupware This is software designed to facilitate distributed collaboration.


1.3 Problem Statement

1.3.1 Introduction

Most of the computer systems in use are based on an old, centralized method of security. The
research that this technical report describes is specifically concerned with the management
of system resources and the management of access control in a distributed computing envi-
ronment. Several systems already exist to facilitate security in a distributed environment,
such as Andrew [38]; however, they still have elements of the old centralized methods. Some
of these systems will be surveyed later.


1.3.2 Security Problems with Distributed Systems

SACM presents the following problems when working in a distributed environment.









1. UserlDs are often duplicated across name-space domains in a distributed system. For
example, two different users may have the same userID on two different computer
systems within a distributed system. This presents a problem when using groupware:
how can each user be unambiguously identified? Currently the only way would be to
append a host computer system identifier to each userID. For example, with a userID
of 'sjg' and a host of 'cis.ufl.edu' we could use the Internet method of '-j' ;- Hn edu'.
This is cumbersome in many cases.

2. Location ht,i,,,'i,, i"i may not be possible. In an application where location trans-
parency is a goal, using a userID and hostID combination is unacceptable. For mobile
users who change hosts often, the combination of userID and hostID fails to uniquely
identify the user. For example, the user with the userID 'sjg' may be identified as
'-j~1; i pkin.cis.ufl.edu' at one time, and maybe identified as '-j 1,.iieleon.cis.ufl.edu'
at another time. This means that using the combination of userID and hostID as a
means of identification results in multiple aliases for the same user. When this is com-
bined with the possibility of two users in different name-space domains having the same
userID, it may result in serious identification problems (e.g., is '-j l;1;ikin.cis.ufl.edu'
the same user as '-j. 11,I--.LX.barry.edu'?). Another problem is that one user may have
two (or more) different userIDs at different locations, causing another identification
problem (i.e., is 'greenwald .1,1, -.x.barry.edu' the same user as '-j ; edu'?).

3. Unique user identifiers based on UserID and HostID combinations may be redundant
to groupware collaborators. In many cases of collaboration the users do not even care
about which computer systems their colleagues are using. For example, two researchers
at different universities collaborating on the same paper are not particularly interested
in cumbersome host computer names-they are only interested in collaborating with
one other.

4. There exists a -.. .,1: link in the chain" effect. This means that security is a prob-
lem since the security of the entire distributed system depends upon the security of
the individual computer systems that are being used within a heterogeneous name-
space. One lax system administration can compromise an entire distributed system
by allowing access to unauthorized users, sharing of userIDs, etc. This results in the
system with the weakest security setting the maximum security quality of the entire
distributed system.

5. In many installations the system administration is reluctant to permit a single user to
have multiple userIDs (this is not a criticism of system administrations-they often
have good reasons for this policy). This makes it difficult for users to test and use
groupware. The reason this point is important is that for many groupware applications
a particular user may need to assume different roles. For example, a user may wish
to simultaneously assume the roles of proff. --..i" and "chairman" for a particular
groupware session. In a groupware system such as the first version of the Distributed
Conferencing System (DCS) [33], the only way to allow this was to change certain
UNIX environment variables. This is an extremely insecure method since there is no
operating system access control regarding the modification of environment variables in









UNIX [2]. However, the constraints imposed upon the developers of DCS Version 1
unfortunately mandated this unsafe practice.

6. It may be difficult to share resources with other users on other computer systems
without getting permission from the system administrations involved. For example,
two users subject to different system administrations who wish to share a file with each
other may find it impossible without using cumbersome methods (e.g., File Transfer
Protocol, electronic mail) that are unsuited for real-time applications.

7. Foreign user accounts are often necessary to correct the previous problem. This places
a management burden on the system administration because it has to manage users
from a foreign environment. In addition, there is the very serious difficulty of the
system administration initially verifying the identify of these foreign users, who are
often not physically present on site.

1.3.3 Comments

The above problems result because most of the security paradigms in use are outmoded.
They are based on the assumption of a centralized access control mechanism dating from
the days when centralized time-sharing mainframes dominated the field. This naturally
resulted in centralized management of system resources, and the implicit condition of location
dependency for users and resources. These conditions were not seen as problems because
the security systems were designed for these single stand-alone systems.


1.4 Technical Report Organization

This technical report is organized as follows. Chapter two is a survey of the relevant work
in the field. Chapter three is a description of the distributed compartment philosophy.
Chapter four is a description of the formal security model which resulted from the philoso-
phy of chapter three. Chapter five is a discussion of the Distributed Compartment Model,
specifically concerning the similarities and differences between the standard model and the
Bell-LaPadula model, alternate models, implementation details, examples of how the model
can be used, and some issues regarding future research. Chapter six concludes the technical
report. In addition, appendix A is a description of some of the mathematics used in the
model, and appendix B is brief overview of the Bell-LaPadula model.














Chapter 2


SURVEY OF RELEVANT WORK



2.1 Introduction

This chapter surveys some of the work in the field of distributed system security that is
relevant to the research described in this technical report.
We first consider an old method, the Access Matrix Model. Next We review the Bell-
LaPadula model, one of the most influential information flow models, along with systems
that are either based on it or have been heavily influenced by it: the Military Message Ex-
periment, Multics, the Kernelized Secure Operating System, and finally Guard. Then we
examine Denning's information flow model. We then consider the Military Message System,
an ambitious project in message based security. Andrew, a system that is currently in use
at Carnegie Mellon University, is next reviewed. Then we consider the ADMIRAL Model,
a distributed computing system based server system. Next comes a review of IX, a disap-
pointing experiment in multilevel secure UNIX. We next review Amoeba, an object based
distributed operating system. Finally, we conclude with some reviews of other, miscellaneous
work.


2.2 Access Matrix Model

2.2.1 Introduction
The access matrix model is based on an operating system view of security (as opposed to the
military based models that follow). It was originally described by Lampson [23] and further
refined by Denning [11], Graham [17], and Harrison, Ruzzo, and Ullman (commonly referred
to as "HRU") [20]. The model is simple and general, and is widely used [24]. It is still a
topic of research, and many modifications of it exist, such as Sandhu's typed access matrix
model [37].

2.2.2 Description
The access matrix model has the following three components.









1. A set of passive objects, for example, files, devices, and other operating system defined
entities.

2. A set of subjects that may actively manipulate the objects. Subjects are themselves
composed of two things: a process and a domain. A domain is a set of constraints de-
termining how subjects may access objects. Subjects may also be objects at particular
times (i.e., passive and operated upon by other subjects).

3. A set of rules governing how the subjects may actively manipulate the passive objects.

The access matrix is a two-dimensional array with each subject occupying a row, and
each object occupying a column. The row and column entry defines the access rights between
the subject and object. Access rights are such things as read, write, append, etc. The access
matrix defines the protection state of the system.
All accesses to objects by subjects are enforced by a reference monitor mechanism that
refers to the access matrix and enforces it. Any improper access attempts should be rejected
by the reference monitor.

2.2.3 Comments

Since the model does not specify what the particular access rules are, it is extremely flexible.
Because of that it has been applied quite widely [34]. However, this very flexibility makes
it quite difficult to verify the security of the system without looking at the entire matrix.
In addition, strict implementations of the matrix usually result in a very sparse matrix.
Because of this, the model is usually implemented as one of the following:

1. the I,7,,,,,',;li list, where each subject is provided with a list of objects that the subject
may access, along with the access modes allowed for those objects;

2. the access control list, where each object is provided with a list of subjects that may
access that object, along with the access rights those subjects have for that object;

3. combinations of the preceding two lists.

This model is suited for a wide variety of applications, and is quite prevalent in many
computer systems, but it does not correspond to common military security requirements
that require a multilevel security approach.
Another problem with this model is that it is typically implemented by allowing the
owner of an object (e.g., a file could be an object) to grant and revoke access to that object
to other users. This makes it even more difficult to manage the system.


2.3 The Bell-LaPadula model

2.3.1 Introduction

The Bell-LaPadula model (BLP) [6] is one of the most influential models in the design of
computer security systems [25]. It is an example of an access control model and is concerned









with the rights of subjects and how they access objects within the system. The model is an
abstraction of a multilevel secure computer system and does not concern itself with any of
the applications on the (hypothetical) system. The basic format of the model is to define
a set of axioms and properties that, when enforced, prevent applications from violating the
security of the system.
The model is composed of subjects which are entities that can initiate actions, and objects
which are passive and are acted upon by subjects. Both of these have security levels. The
security level of a subject is said to be its "clearance," and that of an object is said to be its
"classification."
There are two axioms that are of particular relevance to the research described later in
this technical report. The *-property (pronounced "star property") that prohibits a subject
from ,-.iitng down" to an object that has a lower security level than the subject, and
the simple security rule that does not allow a subject read access of an object to which its
clearance does not "dominate" the level of the object (level i dominates level j if i > j).
These two axioms may also be referred to as "no write down" and "no read up."
It has been noted that systems that strictly enforce BLP are impractical, due to the
need by users to violate the *-property. A typical example is a user who needs to extract a
lower-level (e.g., UNCLASSIFIED) paragraph from a higher-level (e.g., CONFIDENTIAL)
document and then use it in another lower-level document [25]. This does not violate our
intuitive sense of security-it seems to be a permissible thing to do from our human per-
spective, but it is strictly prohibited in BLP.
Because of this limitation, a special set of subjects called trusted subjects are included
in the model. These subjects are explicitly allowed to violate the *-property because it is
assumed that they will never violate the security of the system. Bell and LaPadula state that
these trusted subjects "are those subjects not constrained by the *-property" [6, page 64].
They make the assumption that such trusted subjects "must be shown not to consummate the
undesirable transfer of high level information that *-property constraints prevent untrusted
subjects from making" [6, page 64]. Formally, a trusted subject can read an object at a
particular security level and write to a different object at a lower security level. Significantly,
the model places no restrictions on the behavior of such a trusted subject's violation of the
*-property.
Systems have been designed to implement the trusted subject feature. For example,
KSOS [27] has trusted processes that are permitted to violate the *-property. The problem
with this is that having such things makes it very difficult to determine the actual security
policy that is being administered. In effect, another layer of complexity is added, since the
trusted subjects must be verified to be secure themselves.
In projects that have actually implemented BLP's axioms without trusted subjects, it
was found that the model was overly restrictive [25]. Because of this, trusted subjects, in
some form, have been present in a number of significant security projects. A brief description
of these projects now follows.









2.3.2 Military Message Experiment

The Military Message Experiment (MME) was an evaluation of the usefulness of an interac-
tive message system in an actual military operations environment [43]. The message system
developed was called SIGMA and was used by a large number of military personnel. Tech-
nically MME was a simulation of a secure system due to the fact that it was running on top
of an insecure operating system (TENEX), but it was designed as if it were actually running
on a security kernel. A security kernel is a small, theoretically tamper proof system that is
supposed to enforce a particular security system.
Initially it was decided that SIGMA would strictly adhere to BLP without trusted sub-
jects. This was one of the causes of several of the following problems that arose:

1. The *-property created problems for some of the message system users who needed
to lower the security level of certain information. People make mistakes, and a user
might create a message at a high security level and afterward decide that the message
should have been at a lower level. Strict enforcement of the *-property does not allow
this ,-.iie-down" of information.

2. It was found that some of the messages in SIGMA were of a multilevel nature. For
example, a paragraph in a high security level message might, itself, be of a lower
security level. BLP makes no allowance for this, so the entire message must be treated
at the highest security level present in the message. Later on, a user might wish to
extract the paragraph, but be prevented because even though the user has the original
security level of the paragraph, the model forces the paragraph to have the higher
security level of the entire message.

3. The developers found that there was no provision in BLP for application dependent
security rules. In their particular case, they had a military security rule where certain
users could have release n. i-, i ,.'i and could therefore invoke the release operation. The
details of the release operation are not important (it was needed to certify that certain
military organizations originated the message being released). The important point
was that such operations are not part of the original Bell-LaPadula model and must
be defined outside it.

To solve the first problem, the SIGMA developers used trusted processes. They also noted
that trusted processes helped to a certain extent with the third problem. However, this made
the exact security policy that SIGMA was enforcing difficult for users to understand. This
was not clearly understood initially and led to a serious problem: SIGMA's designers required
user confirmations of actions taken by the trusted processes. They assumed this would add
to the security of the system. It turned out that by adding the trusted processes the security
policy became muddled in the minds of some users. Many users did not fully understand
what the confirmations were for, and just issued them automatically! Obviously, this is not
acceptable, and illustrates one of the problems with trusted subjects.









2.3.3 Air Force Data Services Center Multics


AFDSC Multics is the operating system from which UNIX evolved. In the middle of the
1970's Multics was modified to include the Access Isolation Mechanism (AIM) [25] and the
resulting system is referred to as Multics-AIM. Multics-AIM enforces BLP with "trusted
functions." The trusted functions, when invoked, go through an operating system "gate"
that is designed to enforce access control on segments of objects, to allow security officers
to review user requests to downgrade the security level of objects, and to provide other
"privil, ,. .1 operations.
While the system works and is considered a success, there are difficulties that arise from its
strict adherence to BLP. When users wish to transfer information to other users at different
levels, it requires them to log on and off repeatedly to change their security level. Receiving
mail is a particular problem, since a user at a lower security level is not notified that he has
received mail at a higher level until he logs on at the security level at which the mail was
sent. This resulted in a set of special trusted functions that the system administration was
allowed to use without going through the inconvenience of logging on and off repeatedly.

2.3.4 Kernelized Secure Operating System

The Kernelized Secure Operating System (KSOS) [27] was a security kernel system running
a UNIX compatible interface. It was originally intended to strictly enforce the axioms of
BLP for user programs, but the developers realized that strict enforcement was incompatible
with its functional requirements in certain circumstances. For example, a user was allowed to
reduce the security level of a file that he owned. This required the need for special software
to support such privileges, which was outside the domain of the kernel, and that violated
the axioms of BLP.

2.3.5 Guard

Guard [44] is a system that allows a human operator to monitor and sanitize the queries and
responses between database systems operating at different security levels. Whenever there
is a potential violation of BLP, the human operator reviews the situation interactively, and
is allowed to violate BLP (at least in one version), by allowing information from the system
with the higher security level to be downgraded and passed to the system with the lower
level. In effect, the human operator becomes the trusted process in this system.

2.3.6 Comments

It is clear that the axioms and properties of BLP are overly restrictive in "real world"
applications. This requires the use of trusted subjects that, unfortunately, are not well
defined in the model, and therefore have the potential to become too permissive. With no
formal specification of what a trusted subject can and can not do, the developers of a system
using the model are left on their own as to what is allowable. These criticisms led to the
development of such systems as the Military Message System (a description of which follows
later).









2.4 Other Information Flow Models


2.4.1 Introduction

While BLP is technically an information flow model, it occupies a special place in the field of
computer security due to its emphasis on access control. Other information flow models are
more general than BLP in that they are interested mainly in the flow of information from one
object to another. Access control models such as BLP are more concerned with the exercise
of security rights by subjects and how those rights are applied to objects. Information flow
models differ significantly from the access matrix model in that they can even be applied to
the variables in a computer program (as opposed to the larger objects of the access matrix
model).
Denning's Lattice Model of Secure Information Flow [10] is perhaps the best known
example of an information flow model, although there is a lot of work done in this field, such
as Cuppens' analysis of authorized and prohibited information flows [9]. It will be used as
an example in the remainder of this section, although there are other lattice models such as
Wu, Fernandez, and Zhang's [45].

2.4.2 Description

Denning's flow model is a simple lattice structure with five components:

1. a set of information objects (e.g., files);

2. a set of processes that are the active agents responsible for the flow of information;

3. a set of security classes that are disjoint;

4. class combining operators that operate on information from two classes and specify the
resulting class of information generated;

5. the flow relation, that specifies whether information is allowed to flow from any one
pair of security classes to another.

Denning also makes a distinction between static binding in which objects are bound to
a security class regardless of their contents, and ,.:/ii;'<.- binding where the security class of
an object can change depending on its contents. Denning maintains that static binding is
the most desirable for security reasons. For example, in static binding, an object might be
classified as SECRET even though it contains only lower-level information. This is not the
case in dynamic binding, where the security level of the object would change to match the
highest level of its contents (see the section on IX later in this chapter for an example of a
dynamic binding system).









2.4.3 Comments


The advantage of the information flow models is that, in theory, it is easier to verify the
security of a system than with other models. Flow proofs can be used to demonstrate that
a given set of security assertions hold in a program at a particular place.
However, the flow models appear to me to be rather narrow in scope. Some form of
access control such as an access matrix is probably going to be needed in any "real world"
implementation. In addition, the programming language emphasis may not be wide enough
for all applications. The primary value of the flow models appears to be in proving that
covert storage channels [32] do not exist in the other models. For example, the information
contained in program return codes when a request is denied is not addressed in BLP. Since
the main applicability of the information flow models seems to be at a lower level than the
problem statement of this technical report, the information flow models do not solve the
problem (nor even address the issues).


2.5 Military Message System

2.5.1 Introduction

The Military Message System (MMS) security model has the goal of defining an "integrated
security model that captures the security policy that a military message system must enforce,
without mentioning the techniques or mechanisms used to implement the system or to enforce
the policy" [25, page 205]. As can be seen from the goal statement, it is a message based
model.
One of the primary goals of this model is to allow users to understand the policies of
a message based security system. Other goals are to help the designers of future military
message systems and to facilitate certification of those systems.

2.5.2 Description

The distinguishing concept of MMS is that of a user role. A role is defined as:

The job a user is performing, such as downgrader, release, distributor and so on.
A user is always associated with at least one role at any instant, and the user can
change roles during a session. To act in a given role, the user must be authorized
for it. Some roles may be assumed by only one user at a time (e.g., distributor).
With each role comes the ability to perform certain operations. [25, page 206]

In addition, the authors define the military idea of a security container that is defined
as:

A multilevel information structure. A container has a classification and may
contain objects (each with its own classification) and/or other containers. In
most MMS family members, message files and messages are containers. Some
fields of a message (such as the Text field) may be containers as well. [25, page
206]









It should be noted that devices are also containers. Containers are distinguished from
objects in that objects are atomic: they are single-level units of information. Therefore an
object may not contain another object, and can not be multilevel. Objects can be as simple
as a particular field in a message (the example given in [25] is the date-time group of a
message).
There are many other definitions present in the model, most of them corresponding to
well-known ideas in the areas of multilevel security (e.g., clearance, user, operation, ID, etc.).
The interested reader is referred to Landwehr, Heitmeyer, and McLean [25] for more details
on this.
The importance of all of this from our perspective regarding this technical report is in
the area of how a user views the operation of MMS. Users gain access through logging in by
providing a UserID and passing some form of system authentication. They may then perform
operations depending on the particular roles for which the user is authorized (usually viewing
or modifying objects or containers). Needless to say, the system enforces the security model
(the authors are vague as to how this is actually to be done, instead assuming that the model
will somehow be correctly implemented). Significantly, no provision is made for the auditing
of users. This is a deliberate omission by the authors-they did not forget about it, instead
they ignored the issue after making cursory note of it.
In order to avoid the problems with having vaguely defined trusted subjects, the model
makes the following assumptions.
1. There exists a Sill, Security Officer (SSO) who manages the initial clearances and
classifications, and sets the user roles appropriately.

2. Users must then enter the correct classification of the object or container when they
are accessing the information (i.e., creating, changing the contents, or reclassifying).

3. A user may define access sets within a particular classification, which is a set of triples
composed of users or roles, operations, and operands that are associated with entities.
This results in the ability to create a "need-to-know" capability for other users.

4. The user must properly control information extracted from special containers that have
the property of Container Clearance Required (CCR). Containers with this property are
restricted to users with the appropriate security clearance. Essentially, CCR requires
that a user must have at least the maximum clearance required for any member of the
container.
The rationale behind these rules is that when there is no other source of information about
the security of entities, the user is assumed to correctly provide information. If this were
all there was to the model, it would be obviously unacceptable since users would probably
run riot through a system, transferring classified material to lower levels. However, this is
prevented by the use of user roles. For example, a user can only perform an operation on an
entity if the user or his current role appears in the entities access set with the appropriate
operations and operands. Another restriction is that there is a special role of downgraded
without which a user can not downgrade the security level of any entity. Messages can not
be released unless the user has the role of release. There are other assertions similar to
these that the authors assume will make the model effective.









2.5.3 Comments


The MMS model has been used almost without change by the messaging project Diamond
[14] which is a distributed multimedia document project, and reportedly has been adapted
for use in document preparation and bibliographic systems [1].
We are extremely impressed with the work done on this system. However, while this
model appears good within its context, it does not address all the problems noted in the
problem statement in chapter one. Some specific problems not addressed follow.

1. There is no location transparency. This was not even an issue in the design of MMS.

2. The exact organization of containers is deliberately left vague. Presumably this is so
that application developers will not be hampered with rigid definitions. However, this
seems to raise the same objections that trusted subjects cause with the Bell-LaPadula
model (i.e., the organization of the containers may be overly permissive).

3. Only a user with the role of a System Security Officer can set the roles and clearances
of users. This is not a drawback in the context of the MMS model, but it is possible
that this may place a burden on the System Security Officers, causing bureaucratic
problems and delays.

4. The model does not specify how users are initially created (presumably by some cen-
tralized system administration, although that is just speculation by me).


2.6 Andrew

2.6.1 Introduction

Andrew is a distributed computing environment that is a joint project of Carnegie Mellon
University (CMU) and IBM Corporation [38]. It has been under development since 1'" ;
and is expected to eventually encompass over 5,000 workstations at the CMU campus. The
development of security mechanisms for Andrew has been a major issue in its development.
Its major use is as an information sharing system that uses a distributed file system as its
mechanism.
Andrew is no longer an experimental system, having actually been implemented. It
continues to evolve and grow. At the point of its inauguration in late 1'III there were over
400 workstations serving about 1,200 active users, with a file system storing 15 gigabytes
on 15 servers. Due to the large scale of the system, the developers realized that the typical
academic laissez-faire approach to security would not be practical.
Andrew is considered mature and robust and is in regular use at CMU.

2.6.2 Description

Andrew is composed of two components. Virtue is a set of workstations, while Vice is a
collection of servers and local area networks. Each Virtue workstation runs the UNIX 4.3
BSD operating system. In Virtue, a distributed file system that spans all the workstations









is the primary data-sharing mechanism. The distributed file system appears as a single
large subtree of the local file system. A process called Venus that runs on each workstation
manages the access of files in this shared name space by finding the files on individual servers
on Vice, caching them locally, and then emulating the UNIX operating system.
There are many levels of security in Andrew that are not within the scope of this technical
report (such as the details of how the Vice servers are physically secured). What is of interest
is how the system is managed in terms of group work.
It is common in Andrew that a group of workstations be used by the same pool of users
(e.g., located in the same laboratory). It becomes the joint responsibility of those users to
ensure the integrity of the security of those workstations (both hardware and software). The
developers accept this because there are only a few files stored locally on the workstations
(for initialization purposes mainly).
The protection domain in Andrew is composed of Users and Groups. A user is an entity
that can authenticate itself to Vice (among other things). A group is a set of other groups
and users associated with a user called the Owner. The name of the owner becomes the
prefix for the group owned. There is a special user called "System" which is omnipotent,
corresponding to the UNIX superuser.
Membership in a group can be inherited and the "IsAMemberOf" relation holds between
a user or group X and a group G if and only if X is a member of G. The reflexive, transitive
closure of this relation for X is a subset of protection domains called its Current Protection
Subdomain (CPS) that is the set of all groups that X is a member of directly or indirectly.
The result is that a member of a group inherits all the privileges of any ancestral groups.
This was done to simplify management of privileges due to the scale of Andrew.
Additionally, "group accounts" and "project accounts" are collective accounts shared by
multiple users. The reasons given for these are significant:

1. obtaining an individual entry for each human user may involve excessive administrative
overheads;

2. the identities of users who are collaborating in a group may not be known a priori;

3. the protection mechanisms of Andrew make it easier to create just one ... d.,-. i
and specify the protection policies for that pseudouser than for multiple users.

Finally, since the inauguration of Andrew, it was found necessary to enhance its function-
ality by adding support for multiple Cells. A cell is essentially a "completely autonomous
Andrew system with its own protection domain, authentication, file servers, and system ad-
ministrators" [38, page 277]. Cells are noted as complicating the security mechanisms of
Andrew.


2.6.3 Comments

We feel that the inheritance mechanism of Andrew is inappropriate. We understand why
the designers incorporated it: to make administration easier. However, it seems potentially
dangerous. If the privileges of a higher-level group changes, all the users underneath it will









inherit the changes. This could be disastrous if a management mistake (or security attack)
is made.
We also feel that the need for pseudousers underscores the problems with distributed
system security that we mentioned earlier in the problem statement in chapter one, regarding
the difficulty with system administrations. Although the designers are strongly opposed to
pseudousers, they are forced to permit these collective entities. Significantly, Satyanarayanan
notes that collective pseudousers are created because of the bureaucratic difficulties with
creating groups:

We conjecture that [the creation of collective entities] is primarily because the
addition of a new user is cumbersome at present. In addition, groups can only
be created and modified by system administrators. [38, page 253]

The designers seek to remedy this situation by implementing a protection server that will
allow users to create and manipulate groups themselves, instead of having to rely on system
administrators. We can well understand the need for this (the Distributed Compartment
Model described in this technical report contains something similar) but we feel that this is
potentially very dangerous when combined with inheritance. What is to prevent a user who
has acquired great privileges from creating groups and adding users? It seems like a serious
mistake. Time will tell.


2.7 The ADMIRAL Model

2.7.1 Introduction

Project ADMIRAL is a collaborative project carrying out research into the use and manage-
ment of high performance networks. Stepney and Lord [41] have developed a formal model
for an access control system for ADMIRAL that allows computing facilities from different
system administrations to communicate with each other. Administrators are allowed to re-
tain control of their own subnets. Although this model is not necessarily specific to project
ADMIRAL, to avoid confusion we will refer to it as "the ADMIRAL model."
The basic idea behind the ADMIRAL model is that users can log in to a distributed
computing system and make service requests to any part of the system without having to
identify themselves further. All access control decisions are handled automatically after the
initial logging in procedure and are transparent to the user.
The design of the ADMIRAL model was started in the mid 1'iIs's at GEC Research, at
the Marconi Research Centre in the United Kingdom.


2.7.2 Description

The ADMIRAL model is most concerned with the frustration that users and administrators
face in a network composed of several "autonomous access control systems" that have to in-
teract. Users must repeatedly log in and out, and administrators have to maintain additional
access control information.
A system based on the ADMIRAL model will have the following properties.









1. Autonomous administrations are supposed to be able to work with each other, but
they still retain control over their own facilities.

2. A user's access to specific services can be controlled, even if the user and the service are
under different administrations. This control is supposed to be transparent to users,
unless they try to access restricted services not available for their use.

3. An administrator can make use of another administrator's facilities, as long as they
both agree in advance.

4. Multiple levels of security are available to users and administrations. Users and ad-
ministrators can insist on particular levels for particular operations.

The ADMIRAL model is based on a client-server model. Principals make requests of
clients who handle it by passing it on to a server. Authorities provide the control over
the privileges of the principals (e.g., "JOHN has READ access to FILEx"). Authorities
act as intermediaries between the rights of the principals to access a server. Authorities
communicate with each other and trust statements that other authorities make. Statements
consist of a record of the issuing authority, a principal, a server, and the requests the principal
has permission to make of the server.
An entire client-server cycle is known as a transaction and takes place in the following
steps.

1. A principal makes a request for some service via a client.

2. The client makes the request on the principal's behalf to the Client's Local Authority
(CLA). The CLA holds cached statements about the principal and server that are
obtained from its own store.

3. If the statements needed are not cached, the CLA contacts other trusted authorities
via the network.

4. The request is passed on to the Server's Local Authority (SLA) which then checks the
access rights using its cached statements that are obtained from its own store.

5. If the statements needed are not cached, the SLA contacts other trusted authorities
via the network to obtain the statements.

6. If all the access conditions have been met, the request is passed on to the server for
processing.

7. Further exchange of data may occur at this point after processing.

From this it can be observed that the ADMIRAL model is a type of remote procedure
call system. Obviously, if the principal does not have the proper permissions, the request
should be denied.









2.7.3 Comments


The ADMIRAL model is a simple system. The main problem we see with it is how they
can implement "Trust." The authors note that this caused a lot of problems when they
attempted to implement the model. We suspect that this is the reason that it is not yet fully
implemented. It was impossible for them to formalize exactly what "Trust" is. For example,
they had made assumptions that Trust had to be transitive (if A trusts B, and B trusts C,
then A trusts C). When they formalized this, they realized "that it would be very easy for
all authorities to end up trusting all the others, making the concept of Trust -,. 1. - [41,
page 592]. So they removed that property. The authors are vague on how they finally solved
this problem (we suspect they really haven't completely solved it, but are still experimenting
with different methods).


2.8 IX

2.8.1 Introduction

We debated whether or not to include a section on IX in this technical report. On the one
hand, it is an actual implementation of a multilevel secure UNIX-like system by AT&T Bell
Laboratories _'s]. On the other hand, it was a failure in the "real world" for reasons that
the authors don't detail clearly (but which we can guess). If the authors had detailed the
reasons why IX failed more clearly, we would consider it a more valuable experiment. When
we finished debating with ourselves, we decided to give an overview of IX and why we think
it failed.


2.8.2 Description

IX was designed and built at AT&T Bell Labs as an experimental multilevel secure version
of the UNIX operating system. It supports document classification with mandatory access
control, where classified input must yield classified output. The IX model differs from BLP,
primarily by violating the *-property (although the authors don't explicitly state this).
Every entity in IX has a label associated with it that describes its security classification.
Users can have access only to entities they are cleared for. However, the authors of IX chose
to use dynamic binding: the "labels of processes or files may adjust automatically during
computation to guarantee that outputs are classified at least as high as the inputs from which
they cl. ['- page 673]. Data transfers are allowed only in the direction of increasing
labels.
IX has many other features, but the concept of labels seems the most important. IX
tracks data flows by the use of labels. Every exchange of data must be labeled. However,
because IX uses dynamic binding, labels must be checked every time a data transfer takes
place, not just at the beginning of a transaction. This takes significant processing time.









2.8.3 Comments


According to the authors, IX has not "stood the test of abuse outside the laboratory" -
page 691]. We believe this was because of a problem with dynamic binding systems called
"label creep" which happens when high-level data are placed in low-level files by accident.
This results in "contaminating" the file with no hope of revocation. Obviously, a user would
be reluctant to use a system where he might lose all his data by a simple mistake.


2.9 Amoeba

2.9.1 Introduction

Amoeba is an object based distributed operating system developed at the Free University
and the Centre for Mathematics and Computer Science in Amersterdam [29]. The authors
report that Amoeba is one of the fastest distributed systems of which they have knowledge.
It is a long term project, lasting over 10 years.


2.9.2 Description

Amoeba consists of four hardware components: a processor pool, workstations, and servers
(all connected through a local area network), and a gateway. The idea behind the processor
pool is that the number of processors should exceed the number of users, providing increased
performance (a user can be allocated more than one processor for parallel computations)
and fault tolerance. Workstations are used only as user interfaces (i.e., they only execute
processes that manage the user interface). The servers are traditional file servers, print
servers, etc. The gateways are to other Amoeba systems that can be accessed over a wide
area network.
The Amoeba software is object-based, and is a client-server type system. Every object
is protected by a "capability" which is "the set of operations that the holder may carry out
on the object" [29, pages 45-46].
Amoeba's model makes heavy use of remote procedure calls and threads (light-weight
processes). There is a special server dedicated to finding the location of objects.
Security in Amoeba is a variation of the commonly criticized "security through ol... ', I
method [15]. A client request is addressed to a particular server's port. The authors say
that "knowledge of a port is taken by the system as prima facie evidence that the sender
has a right to communicate with the service" [29, page48]. This is not as bad as it could be,
since a simple cryptographic system is used to make it difficult to determine the proper port
number for various services.


2.9.3 Comments

Amoeba seems more concerned with the protection of objects than with their management,
and this seems to be a serious drawback from the perspective of the problem statement of this
technical report. For example, the authors state "a system manager or project coordinator









cannot hand out capabilities explicitly to every user who may access a shared public object"
[29, page 49]. On the other hand, a user can do this with his own objects. Essentially, the
designers of Amoeba have developed a traditional resource management and access control
policy on a distributed system. This is a great accomplishment, but does not change the
underlying SACM.


2.10 Other Work

We reviewed other work that had little relevance to this technical report, but nonetheless
deserves some passing mention.
Benson, Akyildiz, and Appelbe [7] are concerned with the differences between sequen-
tial security models and concurrent security models and developed a security model they
termed the "Centralized-Parallel-Distributed model" [7, page 183]. Their main emphasis is
on concurrent systems.
Glasgow and MacEwen [16] describe their work on a multilevel secure system called
Snet. Their main interest is in information flow, and a specification language called "Lucid"
which they use to specify distributed systems and prove that formal model components are
consistent. They claim that Lucid is intermediary between a formal model and an actual
system implementation of a multilevel secure system.
Hanushevsky [19] describes the IEEE Mass Storage Reference Model's security. The
model is concerned with protection components, which consist of authentication, autho-
rization, enforcement, and auditing. While there was some discussion of the problems of
authorization in a varied name-space, this paper did not seem particularly relevant to the
topic of this technical report.


2.11 Conclusions

The work reviewed varied from some which were spectacularly successful, to others which
were dismal failures. However, our primary interests were the lessons learned from both the
successes and the failures. They confirmed the items mentioned in the problem statement in
chapter one, and illustrated the need for a new paradigm, which would address the problems
of these I i.l,,itional" security systems.
The next chapter is about our solution to the problem statement, and some of the philo-
sophical considerations that were involved in creating that solution.













Chapter 3


THE DISTRIBUTED

COMPARTMENT MODEL

PHILOSOPHY



3.1 Introduction

The philosophical justifications and a narrative description of the Distributed Compartment
Model are presented here first, before the actual formal security policy model in the chapter
that follows. This is done as an aid to understanding the formal security model in the
following chapter. The development of the formal security policy model was driven by the
following philosophy, so it is only natural to present these ideas first, in an informal way. The
reader interested in the development of formal security policy models in general is referred
to the National Computer Security Center's overview of the modeling process [31]. The
philosophy that follows can be thought of as an organizational security policy.
We would like to emphasize that the philosophy behind the solution to the problem
statement in chapter one was not motivated by the traditional view of a multilevel secure,
categorized system, such as that presented in the famous "Orange Book" of the Department
of Defense" [12]. We believe that this traditional view of "security" can be be a stum-
bling block to some people who try to understand the philosophy behind the Distributed
Compartment Model.
The solution to the problem statement of chapter one has two parts. The first is Dis-
tributed Handles, a means for user identification and access control. The second is Distributed
Compartments, a method for allowing users to manage resources within a distributed system
across computer system boundaries with a measure of independence from any system ad-
ministrations. It will be seen that the Distributed Compartment Model violates BLP insofar
as the *-property is violated. The simple security rule is retained.









3.2 Distributed Handles

The central concept of distributed handles is that for groupware applications userlDs should
be eliminated as a means of identification and access control.
The proposed solution is the concept of a distributed handle, that the groupware applica-
tion uses as an identifier for users. A user joining a groupware session is queried for a handle
that is unique to that application (later we shall see how this uniqueness is guaranteed),
and is then verified by a groupware security manager. This keeps user access to that ap-
plication as separate as possible from the operating system. Verification can be an entirely
independent operation (e.g,. user knowledge, physical attributes, possession of security ob-
jects) using a method such as Kerberos [39], [40], [15]. Passwords will probably be the most
common authentication method.
Under this method, an individual user would first need to gain access to a particular
computer system in the distributed system through SACM by having a valid userID and
password. The user would then need a valid distributed handle and would then need to
be validated by the groupware's access control security in order to be allowed access to the
application.
This approach has several advantages that follow.

1. Security dependencies are reduced. Security is not entirely dependent on an operating
system, system administration, bureaucrats, etc. As things stand now, even one lax
system administration can disrupt security in groupware applications. Some examples
of these security policy violations follow.

Users can be permitted to share accounts with one another. Under this situation
it is impossible to verify the identify of the actual user by the use of userIDs.
Users who have no authorization to use a particular groupware application may
be given permission to access the files used.
Users who need access to a particular application, yet lack the permission to
access the application, may have to wait a long time for the (usually overworked)
system administration to grant the proper permission.

However, it should be noted that it is impossible to protect against poor operating
system security. For example, a distributed operating system could allow the inter-
ception of keystrokes from a workstation over a computer network. This could not be
prevented by this model.

2. Handles can be more descriptive than userIDs. For example, a userID of "sjg" does
not convey much information. With handles there could be a more descriptive name
such as "Steve," "Greenwald," "Third Programmer," "Referee 2," etc.

3. Multiple handles can be permitted for the same user. The advantages of allowing this
follow.

The testing of groupware applications becomes much easier. One user can easily
simulate many users by having several handles.









Anonymity is possible.
Multiple roles for individual users becomes possible. Different handles can be
used for different user roles. A user needing to change roles just needs to use the
appropriate distributed handle.
Intervention by the system administration is limited. The system administration
does not have to be concerned with creating multiple accounts for the same user.

4. Binding of users to roles becomes possible since more than one user may share the
same distributed handle. This allows multiple users to share the same role.

5. Security mechanisms can be implemented relatively independently of any underlying
operating system. Keeping security matters within the particular groupware appli-
cation facilitates development of whatever higher-level operating system paradigm is
wanted, independent of the actual operating system. For example, a new operating
system could be built while using an old one, incorporating separate user accounts.
Testing of experimental security mechanisms becomes easier.

6. Management of handles can be made part of the groupware application, allowing dif-
ferent security methods to be implemented. For example, security can be partitioned
in a hierarchical manner with different people maintaining the handles of their own
compartments (this idea will be discussed later in the distributed compartment sec-
tion).

One area specifically not covered is access control. There are a variety of access control
methods available (e.g., passwords, physical attributes, possession of objects). Specific access
control methods were not an area of research for us, since we feel that this is another problem
entirely, and is separate from the Distributed Compartment Model. However, one important
point is that the system administration will not be responsible for the access control of
distributed handles. That will be the responsibility of the particular groupware application.
This frees the system administration from the burden of managing the handles, and frees
the groupware managers from the necessity of having to access the system administration
every time maintenance is needed for access control.
Distributed Compartments, a description of which follows, is the designated platform for
the access control and administration of distributed handles.


3.3 Distributed Compartments

A distributed compartment (also called a discom) is a logical group of objects that is not
restricted to a single physical computer system. Objects consist of such things as files,
hardware devices, programs, users,[6], [34], [10], and subdiscoms [?]. A discom is conceptually
similar to a standard hierarchical directory structure, however, it does not necessarily reside
on a single computer system. The users of discoms gain access via distributed handles.
A root discom is called an empire discom. An empire discom must have a unique identi-
fying name in the particular name-space domain being used (more on this later).









Discoms have users called subjects. Each discom must have at least one subject called
a governor. Governors have the maximum privileges for the discom they govern. Other
subjects may have lesser privileges.
The privileges of a discom consist of at least 24 operations called the initial privileges:

1. create a new object;

2. destroy an existing object;

3. modify an existing object by adding or removing resources from it;

4. merge two existing objects into a single object;

5. split an existing object into two objects;

6. create a child discom;

7. destroy a child discom;

8. merge two child discoms into a single child discom;

9. split a child discom into two child discoms;

10. destroy an existing empire;

11. merge two existing empires into a single empire;

12. split an existing empire into two empires;

13. create a new subject;

14. destroy an existing subject;

15. create a new privilege;

16. destroy a non-initial privilege;

17. create a governor from an existing subject;

18. rescind a governorship by converting the governor to a non-governor subject;

19. add a resource to the resource pool of a discom;

20. remove a resource from the resource pool of a discom;

21. grant a privilege to a subject;

22. rescind a privilege from a subject;

23. make a subject a member of a child discom;

24. remove a subject as a member of a child discom.









This combination of subjects, objects, and privileges, makes it possible to create a system
similar to an access control matrix in the Distributed Compartment Model.
The Distributed Compartment Model has a set of secure state invariants, consisting of
axioms and properties which formalize it. Their informal definitions follow.

Genesis Axiom This simply states that the initial state of the system is secure.

Divine Right Axiom A subject can create an empire discom only if given that privilege
by the administrators of the system administrations involved. This is the only area
where the system administration need be involved in the management of discoms. The
rationale for this is that the system administration is ultimately responsible for the use
of its system. It should be given the right to restrict the creation of empire discoms.

Temporal Axiom A subject may only access an object with the same time index as the
subject. The rationale for this is to prohibit "time travel" so that (for example) a
subject at the current time is not allowed to modify an object in the past.

Usage Property If a subject is currently accessing an object, it either accessed the object
before the present time, or it requested access of the object before the present time.
The rationale for this is to prevent subjects from accessing objects without requesting
that access through the confines of the model.

Creator Property The creator of a discom automatically becomes a governor of that dis-
com. The rationale for this is that if this property was not present, then it would be
possible to create discoms that were inaccessible to everyone.

Government Property The governor of a discom may grant and revoke privileges to non-
governor subjects of that discom. The rationale for this is that someone has to grant
privileges or nothing will get done. The purpose of the model is to eliminate, as much
as possible, involvement by the system administration. If all subjects had the power to
grant privileges, then anarchy would be the result. Therefore only governors or those
subjects they give this privilege to may have this special status.

Cordon Property Discoms may never intersect with other discoms. The rationale for this
is that if discoms intersected with one another, then information could flow between
them in unrestricted ways, possibly violating the Nova property and the Ceiling prop-
erty (defined later).

Nova Property A non-governor subject may only access a descendant discom if made a
member of that discom by a governor of an ancestor discom (conditional down access).
This is a clear violation of the BLP *-property ("no write down"), hence the name
(a nova is an exploding star). The rationale for this is that governors control their
resources and may allocate them as they wish.

Demesne Property The governor of a discom always has unrestricted access to descendant
discoms. The rationale for this is that a governor, by definition, ",.-i,-i" the resources
of the discom. Since any descendant discoms that exist are part of the resources of









a discom, the governor should not be prohibited from any access to them. In addi-
tion, if a governor could not always access descendant discoms, completely autonomous
discoms could result, creating a potential need for the intervention of the system ad-
ministrations involved, if the governor ever needed access again after the autonomous
discoms prohibited access to him.

Ceiling Property A subject may not access an ancestor discom without being a subject
of that discom. This is not just a restatement of the BLP simple security rule ("no
read up"). The Ceiling property does not allow any access at all of an ancestor discom
without membership. The rationale for this is that the governors of the ancestor
discoms are allowed to manage their resources as they see fit. They may not wish even
write-only access from descendant discoms since that might use up resources (e.g., disk
space) and cause (for example) a denial of service problem, or a covert storage channel
[32].

Sanitation Property Resources that are unused must contain the sanitized value for their
type. The rationale for this is to prevent information from being inadvertently disclosed
through the reuse of resources.
It can be seen from the above description that a distributed compartment is actually
a groupware application, with access to the discoms by distributed handles. Once again,
management of the distributed compartments is not done by the local system administration,
but ultimately by the individual users who are governors of empire discoms (by the Divine
Right axiom).


3.4 Conclusions

The combination of distributed handles and distributed compartments is a reasonable so-
lution to the problem statement of chapter one. Combining these two ideas reveals the
following areas of concern.
1. How should system resources be allocated within the discoms? It should be possible
to implement a system where the resources of a discom are restricted according to a
subject's privileges within that discom (with something analogous to an access control
matrix). For example, limiting the CPU time of a discom member might prove to be
a very valuable thing in a real-world application.

2. What is the best way to manage the distribution of the resources of the discoms over
a distributed computer system?

3. What is the best way to manage the name-space that will occur with this system? Since
each discom is essentially a separate groupware application, it would be desirable if
each discom had its own name-space. This would allow unique distributed handles
within each discom.
These concerns motivated some of the details present in the Distributed Compartment
Model in the following chapter.














Chapter 4


THE DISTRIBUTED

COMPARTMENT MODEL



4.1 Introduction

There is actually more than one Distributed Compartment Model, all very similar to one
another. The first model is termed the Standard Model, which we consider to be the most
desirable model in terms of applicability to the real world. The models which follow the
Standard Model (in the next chapter) are experiments involving slight changes to some of
the attributes of the Standard Model. All the models take the form of a formal security
policy model [31, page 133] in the tradition of BLP.
All the sets used in the models contain a finite number of elements, with the exception
of the time set (defined later).
The notation used for set superscripts, subscripts and accents is generally consistent
throughout the model. Subscripts, superscripts, and accents may be omitted when the
information they would impart is contextual, and therefore redundant. The terms ..ild,"
"empire," and "distributed compartment" which follow, are all defined later. A "hat" is
used to designate a set of a world (e.g., B means set B of a world). A superscript is
used to designate a set of an empire (e.g., Bj means set B of empire j). A subscript is
used to designate a set of a distributed compartment (e.g., Bi means set B of distributed
compartment i). For the elements of a set, subscripts are used as indices (e.g., bk means b
is the kth element of some set). If an item has a double subscript, then the first subscript is
used to indicate a distributed compartment, and the second is an index (e.g., bi,k means the
k^t element of a set in distributed compartment i).
All the sets (with the exception of the time set) and elements are bound to some element
of the time set (defined later). This allows the contents of a set to change from time to time.
If this were not done, the resulting system would be completely static and of no practical
use. In order to designate a set (or the element of a set) at a particular time t, we just place
the time in parenthesis after the name of the set (e.g., B(t) is set B at time t). The time
index may be omitted when the information it would impart is not needed (e.g., all the sets
in a statement are bound to the same time).
Additionally, for a set B in distributed compartment Di in empire Ej in a world, W the









following apply.


1. B3 = Bi = B = {b1, b2,..., b,} is a set in a distributed compartment.

2. For empire E ,
Bj = U B
1 if B1 is a set within a distributed compartment, and is the set of all sets of B/ otherwise:

B = {B, Bi,..., B}.

3. For world W,
B= U B

if Bi is a set within an empire, and is the set of all sets of Bi otherwise:

B ={B, B2,...,B}.


4.2 The Standard Model

4.2.1 Components
The following definitions of the elements of the Standard Model consist of the name and
semantics of the set, followed by the elements of the set.

System Administration (administration) This is an autonomously maintained set of
resources within a world. The set of all administrations in world W is

A= {A1, A2,..., A"}.

A particular administration is a set of resources:

Ak = {rI, 2 * ,...,

The administration function A is a mapping of model components to administrations.
For example, A(o) returns the set of administrations that belong to the resources of
object o.

User This is an entity within a single system administration that uses resources. Users may
be thought of as representing human beings or processes, however, users do not span
system administration boundaries.









Resources These are atomic units of computer systems that can be used to perform com-
putations, communications, and data storage/retrieval. Examples include blocks of
disk storage, peripherals, allocations of CPU time, etc. Resources can be composed
into objects. The Ith resource for administration Ak is denoted by rf. A resource pool
is a collection of resources, not necessarily from the same system administration. For
example, the set of resources that belong to discom i is:

R {= Ia, r', r }.

In the case of resources, the administration function maps the system administration
that the resource belongs to:
A(r) = Ak

The value of a resource is determined by the type of the resource (resource types are
not defined within this model), however, resources have a sanitized value for their type
which is used in conjunction with the sanitation property (defined later). We assume
that resources have some mapping to an undefined value space, of which sanitized (or
unsanitized) values are a subset.
The usage function T is used to determine whether a particular resource in a resource
pool is in use by an object or not. If the object is unused, it is also used to determine
whether the resource is sanitized or not. T(r, t) = a (a denotes "sanil ..1) if the
resource is not being used at time t and is sanitized, T(r, t) = -a if the resource is
not being used at time t and is unsanitized. Otherwise the usage function returns the
particular object using the resource.
The discom function A is used to determine the discom to which a resource is currently
pooled. For example, the assertion that Di is the discom of resource r":

A(r') = D,

is equivalent to
r" e Ri.

System Administrator (administrator) This is the supreme authority for a system ad-
ministration.

Object This is a set of resources that may be accessed by subjects. Objects are passive
and acted upon, and may span several administrations. Examples are files, passivated
subjects, CPU time, and child discoms. An object belongs to exactly one discom. For
example, the set of all objects in discom Di is:

0O = = {o, 02,..,,.

The set of sets of all objects for empire Ej is:

3 = U oi.
1








A given object, o,, is a set of zero or more resources from the resource pool of the
discom to which it belongs (these resources may be from various administrations), for
example:


The administration function A(o) is a mapping of objects to sets of administrations,
defined as follows for A(o), o G O:

A(o) = {A(ri) I r e o}.

It is included so that there is a convenient way to determine the system administrations
that belong to an object's resources.

Distributed Compartment (discom) This is an object that is a 5-tuple associating a
set of subjects Si, a set of objects O;, a set of privileges Pi, an action set ASi (all
defined later), and a resource pool Ri. A discom is not necessarily restricted to a
single, physical, computer system. For example:

D3 = D; = D = (S,, O;, P, AS;, R;)

Discoms do not intersect with one another. Intersection means that for (D; i Dj),

1. O; n O = 0;
2. Pi n P = 0;
3. AS, n ASJ = 0;
4. R; n Rj = 0.

Note that the subject sets may or may not necessarily intersect since the subjects can
range all over an empire: Si n Sj f 0 in some cases (Si n Sj = 0 when discom Di and
Dj happen to have no subjects in common).
The set containing all the discoms in an empire (defined later) is denoted by D3.
The set containing all the discoms in a world (defined later) is denoted by D.
The following projections apply to any discom:

1. IIH(D) = Si is the set of all the subjects in a discom;
2. II2(D) = Oi is the set of all the objects in a discom;
3. HI(Di) = Pi is the set of all the privileges in a discom;
4. H4(Di) = ASi is the action set of a discom;
5. HI(Di) = Ri is the resource pool of a discom.

Since a discom is an object, and objects can span several administrations, a discom can
span several system administrations. The administration function A(D) is a mapping
of discoms to administrations, defined as follows for A(D;):

A(D;) = U {A(r) I ri R;}.









Empire This is a partially ordered set of discoms:


Ej = (Dj, 1+),

where
D CD.
D is ordered as as set of rooted, directed trees within a world with each empire having
the following properties:

1. there is one root discom, DE = DE called the empire discom that has no prede-
cessors and from which there is a path to every other discom in the empire;
2. each discom other than DE has exactly one predecessor.

Formally, a set of empires within a world W containing the set of discoms D must
satisfy the following properties:

1. (E' Ej) = (Di n Di = 0);
2. ( Hk(D) nHk(Dj) = 0) for k = 1, 2, 3, 4, 5;
3. the empire relation {+ must apply (defined later).

Since an empire is composed of discoms, it can span several system administrations.
The administration function A(E) is a mapping of empires to administrations, defined
as follows for A(Ej):
A(E)= U A(Df).
1 I< _
Empire Relation This is a binary relation used to create an empire, denoted by [+ and
pronounced "rules." The empire relation is the transitive closure of the "sires" relation
({). The sires relation applies only to a parent-child relation (e.g., D, I Db means Db
is the child of D,). The sires relation has the following properties for an empire E3:

1. I,,,,,., ly, : (D, Db) = -(Db Da);
2. irreflexzivity: -(D, I D,) V (D, EE);
3. single parenthood: (D, 4 Db) = V (De D,), -(D, 4 Db).

The rules relation is the transitive closure of sires. It has the property of

((D, 1+ Db) A (Db J+ D,)) = (Da + D,).

In addition, there are no cycles allowed for the rules relation:

(D, J+ Db) V (D( J+ D,), -(Db J+ Dc).

Empire discom This is the discom D3 that is the upper bound of an empire (i.e., the root
of the empire tree of discoms). This should not be confused with an empire.









World This is a forest of empires (i.e., an unordered set whose members are empires). A
world is identified by some method that can not be specified in this model. Worlds
should be uniquely identified, but there is no way to guarantee this within the scope
of this model.
W= E= {E1, E2,...,E"}.

Subject This is an active entity that can perform operations on objects by the use of
applications. Subjects are partially ordered by the governs relation (4). A subject
belongs to exactly one empire, but can belong to multiple discoms. The set of all
subjects in empire El is:
S3 = {si, s2,. ..,Sn .
The set of all subjects in discom Di G EE is:

S = S, C Si.

A subject is a tuple of the form:

Sk = (Di, E3, ok),

where Di is the subject's upper discom, Ej is the empire in which the subject is
contained, and ok G Di is the default object which the subject will become when
objectified/passivated (this object also contains all the resources the subject uses in
its upper discom). Subjects may be passivated so that they can be accessed by other
subjects. Note that in the rules that follow, whenever a subject is used in the place
where an object is required, it is assumed that the subject is passivated into its default
object. The upper discom is the highest discom in the empire which a subject may ever
access, in accordance with the Ceiling property (see later). A subject is a member of all
discoms between any arbitrary discom of which he is a member and its upper discom.
The upper discom must rule all other discoms of which the subject is a member.
The following projections apply to any subject:

1. II(sk) = Di is the upper discom of the subject;
2. HI2(sk) = Ej is the empire of the subject;
3. H3(sk) = Ok is the default object of the subject.

Label This is a string created from some world specific alphabet with a world specific
maximum and minimum length. The image of the handle mapping function (defined
later) of the subjects in discom Di is:

Li = L C L.

The set of all labels in use in empire E3 is:

L = U L'.
1








Handle This is the method of subject identification. A handle is a label that results from
a mapping of a subject to a set of labels within an empire. The set of all handles in
empire Ey is:
H3 = {hi, h2 ..., h,.
The set of all handles in discom Di is:

Hf = H, C H'.

Handle Function The handle function H(s) is a mapping of subjects to labels, defined as
follows:

1. H : S 2L where L is the set of all possible labels in world W;
2. every subject must have at least one label: H : s (2L 0);
3. subjects can share the same labels: H(si) n H(sj) # 0 is allowed for i f j.

For any subject si we can say that H(si) is the set of handles for s1.

Privileges These are the actions a subject can perform upon an object within a particular
discom. Privileges are generic and are not restricted to a particular subject or object
within a discom. The set of privileges in discom Di is:

Pi = {Pi, P2, ..., P24, .. ,Pn}

The set of all sets of privileges for empire Ej is:

P3 = {Pl, P2 .. Pn.,

Each privilege is a tuple of the form:

S= (i, D),

where i is the index of the privilege, and D is the discom of the privilege. The index
of a privilege corresponds to an action on a type of object.
As an example, the first privilege, which creates an object from resources in discom Di
is not the same privilege as the one which creates an object from resources in discom
Dj.
The first privileges (starting with pi) of each discom are called the initial privileges
and are reserved for the following:

1. create object;
2. destroy object;
3. modify object;
4. merge objects;
5. split object;









6. create discom;
7. destroy discom;
8. merge discoms;
9. split discom;
10. destroy empire;
11. merge empires;
12. split empires;
13. create subject;
14. destroy subject;
15. create new privilege;
16. destroy non-initial privilege;
17. create governor;
18. rescind governorship;
19. add resource to resource pool;
20. remove resource from resource pool;
21. grant privilege to subject;
22. rescind privilege from subject;
23. make subject member of child discom;
24. remove subject as member of child discom.

The indices of the initial privileges are the same for all discoms, because they refer to
the same types of objects. Note that it would appear that some of the initial privileges
do not have an object to act upon since actions are initiated by subjects using a
privilege upon an object (defined later). However, each one of these privileges does
in fact have an object to act upon. For example, the create discom privilege has the
current discom as its object and results in creating a child discom. Granting privileges
to a subject uses the action set as the object (i.e., the action set is modified).

Request Relation This is a binary relation used to indicate when a particular subject
requests access to a particular object, and denoted by pk. For example, (sk pI Om)
(pronounced "s sub k 1-requests o sub m").

Access Relation This is a binary relation used to indicate that a particular subject accesses
a particular object, and is denoted by Rk. A tuple of the form (sk NI o,) (pronounced
"s sub k 1-accesses o sub m") may be added to the current subject access set (defined
later) of a subject in discom Di, CSAi,k(t + 1) iff (sk, (pi, om)) e ASi(t) and Sk is
accessing om using pi at time t + 1.
If a subject is no longer accessing an object, then the previous tuple must be removed
from that subject's current subject access set. For example: CASk(t + 1) = CAS(t) -
{(Sk NI Om)}.









Governor This is the set of discom subjects that always have the maximum privileges for
that discom and any descendants of that discom. For discom Di, V (p E Pi, o e
O;, g e Gi) = (g, (p, o)) e ASi. A governor is also the governor of any descendant
discoms. The set of all governors in discom Di is:

G\ = G = {gi, g2,. ** ,} C Si.

Oligarch This is the governor of an empire discom. An oligarch governs an entire empire.
The set of all oligarchs for empire Ej is:

Q, = {11, W2,...,, }.

Another way of stating this is to say that 0j = G when Di = DE.

PO Matrix This is a conceptual set consisting of the cartesian product of the privilege set
and the object set within a particular discom. For discom Di:

PO; = (P, x O).

SPO Matrix This is a conceptual set consisting of the cartesian product of the subject set
and the PO Matrix within a particular discom. For discom Di:

SPO; = (S, x PO;).

Action Set This is a subset of the SPO Matrix for discom Di, (ASi C SPOi) that consists
of tuples of the form (sk, (pi, o,)) and is used to determine if subject Sk may access
object m, using privilege pi. This set can be thought of as being a list where each
entry is a subject with the privileges and objects the subject can use. In addition, the
action set of empire Ej is:
ASj = U AS.
1 The action set of world W is:

S U ASj.
1
The following projections apply to any action set's SPO tuple:

1. II(SPO E ASk) = s is the subject of the SPO tuple;
2. I2(SPO e ASk) = (p, o) is the privilege-object tuple of the SPO tuple.

Capabilities Set This is a conceptual subset that is the second projection of the action set
for a particular subject in a particular discom Di:

CS,,k C {(p, o) 3x E AS,, sk = II,(x) A (p, o) = 2(x)}.









This can be thought of as isomorphic to a standard capabilities list, since it consists
of tuples of the form (p, o).
In addition, a change to the standard nomenclature (as noted earlier) is made to some
sets such as the capabilities set. CSi,k indicates the capabilities set of subject Sk in
discom Di.

Time Set This is a set of time indices used to identify discrete moments in a world:

T = {0, 1,..., t,...}.

The time set is required because the system being modeled is not static. The system
can be thought of as being single stepped from one time index to a greater (later) time
index [6]. As a convenience, we set to = 0.
Unless a set B(t) is explicitly changed by a rule (defined later), then B(t + 1) = B(t).

Current Subject Access This is a set of the form:

CSAij(t) = {(sj Nk 01)-.

Such a relation means that subject sj in discom Di is k-accessing object or at time t.
If a subject is not accessing any object at a particular time, then CSAi,j(t) = 0.

Current Access Set This is the set of all the current subject accesses within discom Di
at time t:
CAS,(t) = CSAk(t).
1 The set of all the current subject accesses within empire Ej at time t is:

CAS (t)= U CAS,(t).
1
The set of all the current subject accesses within world W at time t is:

CAS(t)= U CASj(t).
1
Subject Access Request This is a set of the form:

SARi,k(t)= {(sk PI om)}.

Such a relation in SAR(t) means that subject Sk in discom Di is requesting 1-access to
object om at time t. There can be only one request per subject in the subject access
request set (i.e., ISAR(t)i < 1). This is done to help simplify the model (for example,
to eliminate any potential deadlock problems). If a subject is not requesting access to
any object at a particular time, then SARi,k(t) = 0. The triple is a request for access,
not access itself.









Access Request Set This is a set of all the current subject accesses within discom Di at
time t:
ARS,(t) = SARi,(t).
1 The set of all the current subject accesses within empire Ej at time t is:

ARS(t) = U ARSi(t).
1 The set of all the current subject accesses within world W at time t is:

ARS(t) = ARS (t).
1
The purpose of the ARS is to provide a way for the system to request access at time t
and get a response to that request at time t', t' > t.

Governs Relation This is a binary relation (denoted by 4), relative to each discom: 4 C
(Si x Si) for discom Di. It is used to create a lattice of all the subjects in all discoms. In
accordance with the lattice principle, subjects are partially ordered under 4 (a relation
is a partial ordering relation if it is reflexive, antisymmetric, and transitive). If a is
a governor of a discom, then a has the maximum privileges for that discom. If a 4 b
(pronounced "a governs b") then a may do at least everything that b may do (i.e., a
has all of the rights that b has) and may also destroy b:

(a 4 b) = (CSi,b c CS,).

This relation has the following properties for discom Di = (Si, Oi, Pi, ASi, Ri) with
81, Sm, Sn E Si:


2. r, l,.'Cii,, Iry: ((si 4 Sm) A (sm 4 si)) iff (si = Sm), and likewise ((Si 4 sm) A (Si #
Sm)) '(Sm 4 si) (governors do not govern each other);
3. reflexivity: (si 4 si) V (si E G);
4. non- ,.,,'i.,, ii,,','1l, subjects do not have to be comparable, so for two subjects
si, sm : (-(si Sm) A -(sm 4-U s)) is possible;
5. il,;,, /i.'.'l, every non-oligarch subject must be governed by a governor: V s
Q3 3 5', (S' 4 S);
6. least upper bound (LUB): every pair of non-oligarch subjects has a least upper
bound: V ((si Q') A (sm Q )) 3 o, ((w 4 si) A (w 4 sm)).

System State This is a tuple consisting of a world's current access set, and a world's action
set for a particular time t:

SS(t) = (CAS(t), AS(t)).

The set of all systems states is E.









Secure System State This is a system that satisfies the secure state invariants (defined
later). The set of all secure system states is denoted by E.

Rules of Operation This is a set of secure state transition constraints that transform a
system state SS(t) to SS(t'), t' > t:

T = {Ti, T2, ,ni.

It should be emphasized that system states are time variant (i.e., the state of the system
varies with time). The only way that a system state can change is by the application
of a rule.
A rule is a function causing a state transition from one system state to another system
state:
Tk : x 2-" ,-
where p is the set of all requests. All rules are designed to be secure state preserving:
Tk : E x 2 -- E. A state transition is composed of a system state along with an access
request set which is transformed into another system state:

rk : (SS, ARS) H SS',

or,
Tk(SS, ARS) = SS'.

In order to simplify the model, rules are applied one at a time to one subject request
at a time. Since the model is designed for use with distributed systems, we make the
simplifying assumption that all requests are serialized within the particular domain
upon which the rule operates (e.g., a discom, an empire, etc.).
In addition, the operation of rules is atomic. This means that all the steps of a rule must
be executed, or none. This prevents the security of the system from being defeated by
interrupting a rule's transition from one secure system state to another before the rule
was completed, and possibly exploiting a security hole which could result.

Secure State Preserving For any SS(t), if SS(t) is a secure system state, and
Ti(SS(t), ARS(t)) = SS(t'), t' > t where SS(t') is also a secure system state, then r,
is secure state preserving.

System This is all sequences of system states with some initial system state SS(to) which
satisfies the secure system state invariants for all subsequent system states.


4.2.2 Secure State Invariants

The secure state invariants are the properties we want the model to have. In order for
the system to be secure, these properties must always be in effect, which is why they are
termed "invariant." They are related to the traditional idea of invariance used in the field
of program verification in that if they hold before a rule is executed, they should hold after
it is executed. Here, "invariance" is used in the same sense that it is used in BLP [6].








Genesis Axiom The initial system state of the system, SS(to), is secure.

Divine Right Axiom A subject can create an empire discom only if given that privilege
by the administrators of the system administrations) involved. This is the only area
where the system administration needs to be be involved in the management of discoms.

Temporal Axiom A subject may only access an object with the same time index as the
subject:

V (a, b, t, t', j, 1), ((,(t) e Sj(t), Ob(t') e Oj(t')) A (sa(t) NI Ob(t)))
(t = t').

Usage Property If a subject accessing an object does not release the object, it still accesses
it. If a subject did not request an object, it can not access it:

V (a, 1, b, t > to), (s,(t) NI Ob(t)) =

((S,(t 1) NI Ob(t 1)) V (Sa(t 1) P1 Ob(t 1))).
In other words, if a subject is currently accessing an object, it either accessed the
object before the current time, or it requested access of the object before the current
time.

Creator Property The creator of a discom automatically becomes a governor of that dis-
com:
(('Se H(Dj(t))) A (si 6 Dk(t)))
((Dj(t + 1) 1 Dk(t+ 1)) A (si e H,(Dk(t+ 1))) A (s E H,(Dk(t + 1))) A (sit sj)).
Equivalently:

V s IIE (Dj(t)), ((S N6 Dk(t)) A (Dj(t + 1) 1 Dk(t + 1))) S e Gk(t + 1).

Government Property The governor of a discom may grant and revoke any privileges to
non-governor subjects of that discom:

((gi e II(Dj(t))) A (sk Gj(t))) (g< N21 Sk(t)),
and,
((gi e IHi(Dj(t))) A (Sk Gj(t))) (gi N22 Sk(t)).
Cordon Property Discoms may never intersect with other discoms:

V (Di(t) Dj(t)) 4 (Di(t) n D(t) = 0).

Nova Property A non-governor subject may only access a descendant discom if made a
member of that discom by a governor of an ancestor discom (conditional down access):

((t' > t) A (Dj(t) + Dk(t)) A (si e Hi(D,(t)))
Sie li(Dk(tl')) if (g1 E nH(,(t)) N23 Si).









Demesne Property The governor of a discom always has unrestricted access to descendant
discoms:
((si e GC(t)) A (D (t) 1+ Dm(t))) = (si e G.(t)).

Ceiling Property A subject may not access an ancestor discom without being a subject
of that discom:

((si(t) = (Dk, E', oi)) A (Dj(t) 1+ Dk(t))) =t (si 1l(Dj(t))).

Note that this implies that a subject may only access discoms that are either its upper
discom or ruled by its upper discom.

Sanitation Property Resources that are unused must contain the sanitized value for their
type:
(V o O(t), r o) (T(r, t) = a).

4.2.3 The Rules of Operation
Rules take the form of a set of requirements followed by a set of operations. If the require-
ments are not all true, the rule cannot be applied. Each rule starts at some initial time t
and concludes at some time greater than t. This is because a rule may take several discrete
time steps to complete. Each type of privilege access has a corresponding rule.
The secure state invariants will be shown to be truly invariant under these rules through
theorems and their proofs following the individual rules. That is, if all the requirements are
true, then the application of a rule to a secure state will result in a secure state.
If a set is not one of the sets that are in the discom tuple (i.e., S, 0, P, AS, R) or a
member of those sets, then it is conceptual and need not be explicitly maintained. This also
applies to the functions used (e.g., the usage function), which will sometimes be mentioned
when necessary.
A group of lemmas is now introduced prior to the rules and theorems. These lemmas
will be used in the theorems which prove the rules of operation are secure state preserving.

Lemmas

Lemma 1 (Usage lemma): If a rule r is such that any object of the rule is not being accessed
by any subject when the rule begins at initial time t, and the subject requests access to the
object at initial time t, and at time t', t' > t the subject accesses the object, and at time
t", t < t' < t" where t" is the final time of the rule the subject releases the object, then the
Usage property holds.
Proof: The Usage property is concerned only with the proper request/access of an object
by a subject. If the following conditions occur during a rule Tr for a subject si G Si and an
object o G Oj at times t, t', and t" such that t < t' < t" in discom Dj:

1. (si pi o) E ARS,(t);

2. (si Nt o) e CSAj,L(t');









3. (s; NI o) CSAj,;(t");


then the Usage property holds.
Q. E. D.

Lemma 2 (Creator lemma): If a rule r is such that a discom is not created, then the
Creator property holds. For example, if k f 6, 8, 9, and k < 24, and SS(t) E E then rT
does not cause a violation of the Creator property.
Proof: The Creator property is concerned only with the creation of a discom. If a rule
r is applied to SS(t) E E where no discom is created, then the Creator property vacuously
holds.
Q. E. D.

Lemma 3 (Government lemma): If a rule r does not affect the actions of a governor, then
the Government property holds. For example, if k 17, 18, and k < 24, and SS(t) E E
then Tk does not violate the Government property.
Proof: The government property is concerned only with the actions of governors in
granting and revoking privileges to non-governor subjects in a discom. If a rule rT does
not affect the capabilities set of any governor regarding that governor's subject-affecting
privileges, then the Government property must hold. The only rules Tk, k < 24 that have
this affect are T17 and Trs.
Q. E. D.

Lemma 4 (Cordon lemma): If a rule r does not cause any object set 0, privilege set P,
action set AS, or resource set R to add any new elements, then it can't possibly make any
discoms intersect and the Cordon property holds.
Proof: Since discom intersection is defined for discoms Di and Dj where i f j as follows:

1. O n Oj = 0;

2. P n P = 0;

3. AS, n AS, = 0;

4. R; n Rj = 0,

then in general,

((A, n A2 0) A (A' C A,) A (A A2)) (A n A 0).

Therefore if rule r does not add elements to {O0 | OE )}P, P {AS AS e AS},
and {R R R}, then it must be of the form: ((A' C A1) A (A' C A2)) = (A n A 0),
and it can not possibly cause a discom intersection, and therefore the Cordon property holds.
Q. E. D.

Lemma 5 (Nova lemma): If SS(t) E E and if a rule r begins at time t and ends at time
t', t' > t, and V j, (S,(t') Gj(t')) C (S,(t) Gj(t)) then the Nova property holds.









Proof: The Nova property is concerned only with a non-governor subject accessing a
descendant discom. If a rule is applied to SS(t) G E such that a new subject is not added to
any discom's subject set then the Nova property holds because if a new subject is not added
to the subject set then there can not be any new privileges that the (non-existent) subject
can use in a discom.
Q. E. D.

Lemma 6 (Demesne lemma): If SS(t) G E and a rule T does not affect the access of
governors of the descendants of a discom, then the Demesne property holds. That is, if
V j, Gj(t) = G(t') when Tk(SS(t), ARS(t)) = SS(t') then the Demesne property holds.
Proof: The Demesne property is concerned only with a governor's ability to access a
descendant discom: ((Dj ,+ Di) A (g, E Gj)) = (g, c Gi). If a rule is applied to SS(t) G E
such that no change is made to any governor set in a descendant discom, then the Demesne
property vacuously holds.
Q. E. D.

Lemma 7 (Ceiling lemma): If SS(t) E E and a rule r does not affect how a subject
accesses an ancestor discom, then the Ceiling property holds. That is, if V i, a, CSi,a(t) =
CSi,,(t'), t' > t for s, when Tk(SS(t)E, ARS(t)) = SS(t') and the change to CSgi,(t') does
not affect the subject's access of an ancestor discom, then the Ceiling property holds.
Proof: The Ceiling property is concerned only with a subject not being allowed to access
an ancestor discom without also being a subject of that ancestor discom: V a, i, j, ((s, e
S,) A (Dj ,+ Di)) => (s, HI(Dj)). If a rule is applied to SS(t) E E such that no subject
access is made to an ancestor discom, then the Ceiling property vacuously holds.
Q. E. D.

Lemma 8 (Sanitation lemma): If SS(t) E E and a rule T does not affect any re-
sources, then the Sanitation property holds. That is, if T(r t) = T(r t') V i, j when
Tk(SS(t), ARS(t)) = SS(t') A (t' > t) then the Sanitation property holds.
Proof: The Sanitation property is concerned with unused resources containing the san-
itized value for their type. If a rule is applied to SS(t) E E such that no resources are
affected: T(rI, t) = T(r, t'), t' > t, then the Sanitation property vacuously holds.
Q. E. D.

TI: Object Creation Rule
When a subject s, in discom Di requests the creation of a new object o", at time t then the
following must occur.

1. Requirement: sc(t) must have the "create object" privilege pi in its capabilities set:
(pi, ASi) e CSi,(t).
2. Requirement: The access request set ARSi(t) must contain a tuple of the form (s, pi (o,, ASi)).

3. Requirement: o,(t) must not exist: on, Oi(t).








4. Requirement: o,(t + 1) must be composed of unused resources r E Ri(t) such that
T(r, t) = a:

V rv, rj E o,(t + 1) t> (rj E Ri(t)) A (T(rj, t) = a).

5. Operation: CSAi,c(t + 1) = CSAi,c(t) U {(s, N1 (o, ASi))}.

6. Operation: When the previously unused resources have been allocated to on(t + 1) the
usage function T must return that object for each resource that now composes o+(t+1).
For example, if o,(t + 1) is to be composed of resource rg then T(rg, t+1) = on(t +1).

7. Operation: o,(t+1) must be added to the set 0(t+1: (t+) : = 0(t) U{on(t+1)}.

8. Operation: The action set of all the governors of Di must be updated to allow each
governor the maximum access to O,(t + 1):

ASi(t + 1) = ASi(t) U {(gj, (pi, o,)) V gj E Gi(t + ), I = 2, 3, 4, 5}.

9. Operation: CSAi,1(t + 2) = CSAi,,(t + 1) {(s, 1I (o,, ASi))}.

10. Operation: ARSi(t + 2) = ARSi(t) {(s, pi (os, ASi))}.

Theorem 1 (Object Creation Theorem): ri is secure state preserving.
Proof: Assume that SS(t) e E contains a discom Di which contains a subject s, which
requests the creation of a new object o, at time t.

1. Usage property: by lemma 1 from (2), (5), and (9).

2. Creator property: by lemma 2.

3. Government property: by lemma 3.

4. Cordon property:

by (7) the object set Oi has increased: V j i, Oj(t + 1) = Oj(t) and o, Oj(t)
since /3o,(t) (by (3)) and 0(t) n Oj(t) = 0 (by the assumption that SS(t) is a
secure system state) and 0(t + 1) 0(t) = {o,} therefore (t + 1) n Oj(t + 1) =
{o,} n O(t)= 0;
Pi is not affected: Pi(t) = Pi(t + 1);
by (8), ASi does not intersect any other action set: Vj / i, ASi(t) n ASj(t) = 0,
and ASj(t+1) = ASj(t), and Aon(t) (by (3)), and o, = { H2( 2(x)) I x e AS(t+
1)-AS,(t)}, so on, { n2( n2(x)) x E AS,(t)}, therefore Vj Z i, ASnASj = 0;
R, is not affected: Ri(t) = Ri(t + 1);

therefore the Cordon property holds.

5. Nova property: by lemma 5.









6. Demesne property: the only change to the privileges of the governors of Di is by (8),
and this change is an addition to their privileges, and does not affect their access to
descendant discoms: if (g Gi(t)) A (Di(t) J+ Dj(t)) = (g Gj(t)) then g Gj(t+1).
Therefore the Demesne property holds.

7. Ceiling property: by lemma 7.

8. Sanitation property:

By (4) all resources are initially unused: T(r, t) = a at time t;
by (6) all modified resources are assigned to the new object o, : T(r, t + 1) =
o (t + 1);

therefore the Sanitation property holds.

Q. E. D.

T2: Object Destruction Rule
When a destroyer subject sd in discom Di requests the destruction of an existing object o,,
at time t then the following must occur.

1. Requirement: Sd(t) must have the "destroy object" privilege p2 in its capabilities set:
(p2, oe) E CS,;d(t).
2. Requirement: the access request set ARSi(t) must contain a tuple of the form (sd p2 oe).

3. Requirement: the object o, must exist at time t : o, G Oi(t).

4. Requirement: the current access set CASi(t) must not contain any triples which contain
o, (i.e., no subjects may be accessing the object at the time of destruction): (s, Nb o,)
CASi(t) V a, b.

5. Operation: CSA,d(t + 1) = CSA ,d(t) U {(sd N2 Oe)}

6. Operation: all the resources of o, must be sanitized, such that the usage function T at
time t must return a for each resource that previously composed o :
(r G oe(t)) (T(r, t +) = a).

7. Operation: o, must be deleted from Oi(t + 1) : Oi(t + 1) = Oi(t) {o}-.

8. Operation: the action set ASi(t +1) must be modified to delete all tuples which contain
the destroyed object o, : AS(t + 1) = AS(t) {(s, (p, o,)) s S,(t), p G Pi(t + 1)}.

9. Operation: CSAi,d(t + 2) = CSAi,d(t + 1) {(sd 2 o,)}.

10. Operation: ARS,(t + 2) = ARS,(t) {(sd p2 Oe)}.









Theorem 2 (Object Destruction Theorem): T2 is secure state preserving.
Proof: Assume that SS(t) e E contains a discom Di which contains a subject sd which
requests the destruction of an existing object o, at time t.

1. Usage property: by lemma 1 from (2), (5), and (9).

2. Creator property: by lemma 2.

3. Government property: by lemma 3.

4. Cordon property: Oi shrinks, Pi does not change, AS; shrinks, and Ri does not change.
Therefore by lemma 4 the Cordon property holds.

5. Nova property: by lemma 5.

6. Demesne property: by lemma 6

7. Ceiling property: by lemma 7.

8. Sanitation property: by (6), all of the resources which made up the object that was
deleted, o,, are sanitized and returned to the resource pool Ri of discom Di : (r e
o,(t)) = (T(r, t + 1) = a), therefore the Sanitation property holds.

Q. E. D.

T3: Object Modification Rule
This encompasses addition (s3A) and subtraction (35s) of resources from objects, and not a
change of data within the object (e.g., changing the contents of a memory cell).
T3A: when a modifier subject s, in discom Di requests the addition of a resource r to
an existing object, o,, at time t then the following must occur.

1. Requirement: s,(t) must have the "modify object" privilege p3 in its capabilities set:
(1, oe) CS;,(t).

2. Requirement: the access request set ARSi(t) must contain a tuple of the form (s, p3 (ri o0)).

3. Requirement: r' must exist in the resource pool Ri(t) of discom D;(t) : r E Ri(t).

4. Requirement: the object o, must exist at time t : o, e Oi(t).

5. Requirement: the resource to be added must be sanitized: T(ra, t) = a.

6. Operation: CSAi,,(t + 1) = CSAi,,(t) U {(s, 3 (r, o6))}.

7. Operation: the usage function for the resource must return the object:
T(rl, t+ 1) = 0.

8. Operation: r, is added to o,(t + 1) : o,(t + 1) = o,(t) U {r'}.









9. Operation: CSAi,,(t + 2) = CSAi,,(t + 1) {(s, 3 (r 0))}.

10. Operation: ARSi(t + 2) = ARSi(t) {(s p3 (r, Oe))}.

Theorem 3A (Object Modification Theorem A): T3A is secure state preserving.
Proof: Assume that SS(t) E E contains a discom Di which contains a subject sm which
requests the addition of a resource r to an existing object o0 at time t.

1. Usage property: by lemma 1 from (2), (6), and (9).

2. Creator property: by lemma 2.

3. Government property: by lemma 3.

4. Cordon property: There is no change to Oi, Pi, ASi, or Ri, therefore by lemma 4 the
Cordon property holds.

5. Nova property: by lemma 5.

6. Demesne property: by lemma 6.

7. Ceiling property: by lemma 7.

8. Sanitation property: by (5), the resource which is merged with the object o, is sanitized.
By (7) and (8) the unsanitized resource belongs to o, : (T(r', t) = a) A (oe(t + 1)
oe(t) U {r'}) A (T(r', t + 1)= oe), therefore the Sanitation property holds.

Q. E. D.
T3S: when a modifier subject s, in discom Di requests the subtraction of a resource rI
from an existing object o0, at time t, then the following must occur.

1. Requirement: Sm(t) must have the "modify object" privilege p3 in its capabilities set:
(p oe) 6 CS;,m(t).
2. Requirement: the access request set ARSi(t) must contain a tuple of the form (sm p3 (ra, Oe)).

3. Requirement: the object o, must exist at time t : o, E O(t).

4. Requirement: ra must exist in the resource pool Ri(t) of discom Di : r Ri(t).

5. Requirement: T(ra, 1)= o0.

6. Operation: CSAi,m(t + 1) = CSAi,m(t) U {(s, 3 (r, Oe))}.

7. Operation: T(r I + 1) = o.

8. Operation: ra is subtracted from o,(t + 1) : o(t + 1) = oe(t) {r'}.

9. Operation: CSAi,m(t + 2) = CSAi,m(t + 1) {(s N3 (r Oe))}.

10. Operation: ARS(t + 2) = ARSi(t) {(, p3 (ra, o0))}.

45









Theorem 3S (Object Modification Theorem S): T3S is secure state preserving.
Proof: Assume that SS(t) e E contains a discom Di which contains a subject s, which
requests the subtraction of a resource r' from an existing object o, at time t.

1. Usage property: by lemma 1 from (2), (6), and (9).

2. Creator property: by lemma 2.

3. Government property: by lemma 3.

4. Cordon property: There is no change to Oi, Pi, ASi, or Ri, therefore by lemma 4 the
Cordon property holds.

5. Nova property: by lemma 5.

6. Demesne property: by lemma 6.

7. Ceiling property: by lemma 7.

8. Sanitation property: by (7), the resource being subtracted from o, must be sanitized:
(o(t + 1) = (oe(t) {r'})) = (T(r', t + 1) = o). Therefore the Sanitation property
holds.

Q. E. D.

T4: Object Merging Rule
When a subject sm in discom Di requests the merging of two objects Oa and ob into a third
object o, at time t, then the following must occur.

1. Requirement: s,(t) must have the "merge objects" privilege p4 in its capabilities set:
(p4, Oa), (p4, Ob) e CSim(t).

2. Requirement: the access request set ARSi(t) must contain a tuple of the form (sm p4 (o0, Ob, o)).

3. Requirement: the objects to be merged, Oa and ob must exist in Oi(t) : Oa, ob e Oi(t).

4. Requirement: the object which will be the result of the requested merge, o,, must not
exist at time t : o, Oi(t).

5. Requirement: there must be only one triple in the current access set CASi(t + 1) that
contains Oa and ob, and it must be (sm N4 (o0, Ob, Oc)) (i.e., no other subject is accessing
them).

6. Operation: CSAi,m(t + 1) = CSAi,(t) U {(s, N4 (o0, Ob, 0,))}.

7. Operation: the new object, o,(t + 1) must be created and added to the object set:
O((t + 1) = Oi(t) u {oc(t + 1)}.








8. Operation: the resources of the two objects to be merged, o,(t) and ob(t) must be
deleted from o,(t + 1) and ob(t + 1) and moved to oc(t + 1) resulting in o,(t + 1) = 0
and Ob(t + 1) = 0.

9. Operation: the resources of the new object, oc(t + 1) must be equal to the resources of
the old objects o,(t) and ob(t): Oc(t + 1) = o,(t) U ob(t).

10. Operation: the old objects o,(t + 1) and ob(t + 1) must be deleted from Oi(t + 2)
O (t + 2) = Oi(t + 1) {o,(t + 1), Ob(t + 1)}.
11. Operation: the action set ASi(t+2) must be modified to delete all tuples which contain
the deleted objects oa and ob : ASi(t + 1) = AS(t) {(s, (p, o)) | (o = o) V (o =
ob), p e P(t)}.
12. Operation: the action set ASi(t + 2) must be modified to include the new object
o, : AS(t + 2) = ASi(t + 1) U {(s, (p, o,)) | 3s e Si(t), p e Pi(t) such that
((s, (p, o,)) E ASi(t) or (s, (p, ob)) E ASi(t))}.
13. Operation: CSAi,m(t + 2) = CSAi,m(t + 1) {(s 4, (o,, Ob, c))}.

14. Requirement: ARSi(t + 2)= ARSi(t) {(s, p4 (o0, Ob, o,))}.

Theorem 4 (Object Merging Theorem): T4 is secure state preserving.
Proof: Assume that SS(t) E contains a discom Di which contains a subject s, which
requests the merging of two objects o, and ob into a third object o, at time t.

1. Usage property: by lemma 1 from (2), (6), and (13).

2. Creator property: by lemma 2.

3. Government property: by lemma 3.

4. Cordon property:

by (7) the object set 0, has increased: V j i, Oj(t + 2) = Oj(t) and o, Oj(t)
since /Qo(t) (by (4)) and O(t) n Oj(t) = 0 (by the assumption that SS(t) is a
secure system state) and O(t+2)- O(t) = {o} therefore O(t+2)n O(t+2) = 0;
P, is not affected: Pi(t + 2) = Pi(t);
lemma 4 applies to AS, at time t + 1 since nothing was added to it;
by (12) ASi(t + 2) does not intersect any other action set: V j i, ASi(t +
2) n ASj(t + 2) = 0, and ASj(t + 2) = ASj(t), and /9o,(t) (by (4)), and o, =
{ n2( n2(x)) | x AS,(t + 2) ASi(t)}, so o, { H2( n2(x)) | x E ASj(t)},
therefore V j i, ASi(t + 2) n ASj(t + 2) = 0;
Ri is not affected: Ri(t + 2) = Ri(t);

therefore the Cordon property holds.








5. Nova property: by lemma 5.

6. Demesne property: by lemma 6.

7. Ceiling property: by lemma 7.

8. Sanitation property: by lemma 8.

Q. E. D.

T5: Object Splitting Rule
When a subject s, in discom Di requests the splitting of an object oc into two other objects
o, and ob then the following must occur.

1. Requirement: s, must have the "split object" privileges ps in its capabilities set:
(/, oc) CSi,(t).
2. Requirement: the access request set ARSi(t) must contain a tuple of the form (s, p5 (o0, Oa, ob)).

3. Requirement: the object to be split, o, must exist in Oi(t) : o, e Oi(t).

4. Requirement: the objects that are the result of the split, o, and ob must not exist in
O (t) : oa Oi (t) A ob Oi(t).
5. Requirement: the current access set CASi(t) must contain only one triple with o, in
it, and it must be of the form (s, R5 oc) : CASi(t) = {(s RN5 o0)}.

6. Operation: CSA,,(t + 1) = CSAs(t) U {(s, R5 (o0, ~, Ob))}.

7. Operation: the new objects, o, and ob are created and added to Oi(t + 1) : O(t + 1) =
Oi(t) U {o1(t + 1), Ob(t + )}.

8. Operation: the resources of the split object o,(t) must be allocated in any manner
chosen by s, among the two new objects o,(t+ 1) and ob(t+ 1), and the resources must
be subtracted from oc(t + 1) (i.e., o,(t + 1) = 0), so that o,(t + 1) U ob(t + 1) = Oc(t)
and o,(t+ 1)ob(t+ 1) = 0.

9. Operation: s, must release access to the object o, that was split from the current access
set: CASi(t + 1) = CASi(t) {(s, N o,)}.

10. Operation: the old object oc(t) must be deleted from O(t + 2) : O(t + 2) = Oi(t +
1)- {o(t + 1)}.
11. Operation: the action set, ASi(t+1) must be modified to delete all tuples which contain
the split object o,(t + 1) : ASi(t + 1) = AS(t) {(s, (p, o)) s G S,(t), p G Pi(t)}.

12. Operation: the action set, ASi(t + 2) must be modified to include the new objects
o,(t + 2) and ob(t + 2) : V d, e, ((Sd, (pe, o,)) G ASi(t)) > ((s8, (pe, on)) E
AS(t + 2)) A ((Sd, (pe, Ob)) E ASi(t + 2)).








13. Operation: CSAi,,(t + 2) = CSAi,,(t + 1) {(s, 5 (oc o, Ob))}.


14. Operation: ARS,(t + 2) = ARS(t) {(s, p, (o,, o, Ob))}.

Theorem 5 (Object Splitting Theorem): T is secure state preserving.
Proof: Assume that SS(t) E E contains a discom Di which contains a subject s, which
requests the splitting of an object Oa into two other objects Oa and ob at time t.

1. Usage property: by lemma 1 from (2), (6), and (13).

2. Creator property: by lemma 2.

3. Government property: by lemma 3.

4. Cordon property:

by (7) the object set 0, has increased: Vj Z i, Oj(t+2) = O(t) and oa, ob Oj(t)
since /3oa(t), and /3ob(t) (by (4)) and Oi(t) n Oj(t) = 0 (by the assumption
that SS(t) is a secure system state) and Oi(t + 2) Oi(t) = {o1, ob} therefore
Oi(t +2) n O(t +2)= 0;
P, is not affected: Pi(t + 2) = Pi(t);
AS, at time t+1 is not affected since nothing was added to it: AS;(t+1) = ASi(t);
by (12) ASi(t + 2) does not intersect any other action set: V j i, ASi(t + 2) n
AS(t + 2) = 0, and AS(t + 2) = ASj(t), and /oa(t), ob(t) (by (4)), and Oa, ob =
{ H2( n2(x)) x E AS,(t + 2) AS,(t)}, so o ob { H( H2(x)) I x AS(t)},
therefore V j i, AS, n AS, = 0;
R, is not affected: Ri(t + 2) = Ri(t);

therefore the Cordon property holds.

5. Nova property: by lemma 5.

6. Demesne property: by lemma 6.

7. Ceiling property: by lemma 7.

8. Sanitation property: by (8) the resources of the split object oc(t) are allocated between
the two new objects o,(t + 1) and Ob(t + 1), and the resources must be subtracted from
o(t + 1). V r E R, (T(r, t) = a) = (T(r, t + 1) = a), (T(r, t) E O {o,}) )
(T(r, I + 1) = T(r, t)), (T(r, t) = o,) j ((T(r, t + 1) = oa) V (T(r, t + 1) = Ob))
Therefore the Sanitation property holds.

Q. E. D.








T6: Discom Creation Rule
When a creator subject s, in discom Di requests the creation of a new discom Dj, at time t
then the following must occur.

1. Requirement: s,(t) must have the "create discom" privilege pi in its capabilities set:
(/., Di) CSi,jt).

2. Requirement: the access request set ARSi(t) must contain a tuple of the form (s8 p6 (Di, Dj)).

3. Requirement: the discom to be created, Dj, must not exist at time t : /Dj(t).

4. Operation: CSAi,,(t + 1) = CSAi,,(t) U {(s, N6 (Di, Dj))}.

5. Operation: the new discom Dj(t+l) must be a child of Di(t+1) : Di(t+1) I Dj(t+1).

6. Operation: s, G Di(t) must become the first subject sli Sj(t + 1) of the new discom
Dj(t + 1).

7. Operation: all the governors ., E Gi(t) must become subjects of Sj(t+1) : Gj(t+1) =
Gi(t). These governors are known as the initial subjects of Dj.

8. Operation: s, must become the first governor gi of the new discom Dj(t + 1) : sc =
gl E Gj(t + 1). The rest of the initial subjects also become governors of Dj(t + 1) :
V gE Gi(t), g E Gj(t + 1).

9. Operation: Oj(t + 1) = 0.

10. Operation: Pj(t + 1) must contain only the initial privileges.

11. Operation: ASj(t + 1) = 0 since there are no objects: Oj(t + 1) = 0.

12. Operation: Rj(t + 1) must be allocated a set of unused resources from the parent
discom's resource pool such that Ri(t) = Ri(t+1)URj((t+1) and Ri(t+ 1)nRj(t+1) = 0
and V r E Rj(t + 1) -> T(r, t) = a.

13. Operation: CSAi,,(t + 2) = CSAi,c(t + 1) {(s, (Di, Dj))}.

14. Operation: ARSi(t + 2) = ARS,(I) {(s, p6 (Di, Dj))}.

Theorem 6 (Discom Creation Theorem): T6 is secure state preserving.
Proof: Assume that SS(t) G E contains a discom Di which contains the subject s8 which
requests the creation of a child discom Dj at time t.

1. Usage property: by lemma 1 from (2), (4), and (13).

2. Creator property:

by (6) s, III(Di(i));
by (1) and (2) (s, N6 Dj);








by (5) Dk(t + 1) I Di(t + 1);
by (6) s, = (si E S (t + 1));
by (7) and (8) s, = (g, e G (t + 1));

therefore the Creator property holds.

3. Government property:

by (7) E G (t) are members of Sj(t + 1);
by (8) S (t + 1) = G(t 1+);

therefore the Government property holds.

4. Cordon property:

by (9) Oj(t + 1) = 0 therefore V k, k O j, Ok(t + 1) n Oj(t + 1) = 0;
by (10) Pj(t + 1) contains only the initial privileges, which are bound to discom
Dj(t + 1) by definition, therefore: V k, k j, Pj(t + 1) n Pk(t + 1) = 0;
by (11) ASj(t + 1) = 0 therefore V k, k f j, ASj(t + 1) n ASk(t + 1) = 0;
by (12) R(t + 1) n Rj(t + 1) = 0 and V k, k j, Rk(t +1) Rj(t + 1) = 0 since
Rk(t + 1) = Rk(t), Rk(t) n Rj(t) = 0 by the assumption that SS(t) is a secure
system state, and Rj(t + 1) C Ri(t) (this is also true for Ri(t + 1));

therefore the Cordon property holds.

5. Nova property: this property applies only after the creation of a discom, however, when
Dj(t + 1) is created Sj(t + 1) = Gj(t + 1) U {s}, therefore the Nova property holds.

6. Demesne property:

by (7) the members of Gi(t) become subjects of Sj(t + 1);
by (8) Sj(t + 1) = Gj(t + 1);

therefore the Demesne property holds.

7. Ceiling property: By (11) the action set of Dj(t + 1) is empty, therefore the subjects
of Dj(t + 1) can not access Di unless they are already members of Di. Additionally,
Dj has no children. Therefore the Ceiling property holds.

8. Sanitation property: by (12) Rj(t + 1) = Ri(t) Ri(t + 1); therefore the Sanitation
property holds.

Q. E. D.








T7: Discom Destruction Rule
When a governor gd in a discom Dj which sires a discom Di requests the destruction of
discom Di at time t, then the following must occur.

1. Requirement: gd must have the "destroy discom" privilege p7 in its capabilities set:
(p7, Dj) e CSjd(t).
2. Requirement: the access request set ARSj (t) must contain a tuple of the form (gd p7 Di).

3. Requirement: the discom Di(t) to be destroyed must rule no other discoms (i.e., it
must have no descendants): -(Di(t) J+ Dk(t)) V i z k.

4. Operation: CSAj,d(t + 1) = CSAj,d(t) U {(gd 7 Dj)}.

5. Operation: the action set ASi(t+ 1) of discom Di(t+ 1) must be emptied: ASi(t+ 1) =
0.

6. Operation: the subject set Si(t+1) of discom Di(t+1) must be emptied: Si,(t+1) = 0.

7. Operation: the privilege set Pi(t+1) of discom Di(t+1) must be emptied: Pi(t+1) = 0.

8. Operation: every object in Di(t + 1) must be emptied by returning the resource of
every object in Di(t + 1) to the resource pool of the parent discom, Dj(t + 1) in a
sanitized state: V o E O@(t), V r e o, ((T(r,t + 1) = o) A (A(r) = Dj(t + 1))). This
means that Vo e O((t + 1), o(t + 1)= 0.

9. Operation: all the (now empty) objects in Oi(t + 2) must be deleted: Oi(t + 2) = 0.

10. Operation: all the members of the tuple of discom Di(t + 3) must be deleted, causing
Di(t + 3) to cease to exist.

11. Operation: CSAj,d(t + 3) = CSAj,d(t + 2) {(gd N7 D)}.

12. Operation: ARSj(t + 3) = ARS(t) {(gd p7 Di)}.

Theorem 7 (Discom Destruction Theorem): T7 is secure state preserving.
Proof: Assume that SS(t) E E contains a governor gd in discom Dj that sires a discom
Di, and gd requests the destruction of discom Di at time t.

1. Usage property: by lemma 1 from (2), (4), and (11).

2. Creator property: by lemma 2.

3. Government property: by lemma 3.

4. Cordon property: by (8) every object in Di(t + 1) must be emptied by returning the
resource of every object in Di(t+ 1) to the resource pool of the parent discom, Dj(t+ 1)
in a sanitized state: V o E O@(t), V r E o, ((T(r,t + 1) = a) A (A(r) = Dj(t + 1))).
Therefore the Cordon property holds.









5. Nova property: by lemma 5.


6. Demesne property: by lemma 6.

7. Ceiling property: by lemma 7.

8. Sanitation property: by (8) all resources from the discom to be deleted, Di must be
sanitized before being returned to the resource pool Rj of the parent discom Dj :
V (r G (o, E O;(t))) = T(r, t + 1) = o. Therefore the Sanitation property holds.

Q. E. D.

Ts: Discom Merging Rule
There are various ways to merge discoms. It was decided that only the merging of two sibling
discoms would be allowed at any one time, in order to ensure that the secure state invariants
would not be violated (e.g., the Ceiling property). The rule now follows.
When a governor subject (g, e Gk) in the parent discom Dk of two sibling discoms Di
and Dj (i.e., Dk D; and Dk Dj) requests that the siblings be merged at time t then the
following must occur.

1. Requirement: g, E Gk(t) must have the "merge,1 ..in- privilege ps in its capabilities
set: (/,. Dk) G CSk,,(t).

2. Requirement: the access request set ARSk(t) must contain a tuple of the form (g, ps (Di, Dj, Di))
which indicates that discoms Di and Dj are to be merged into discom DI such that Dk
will sire DI when the rule has finished.

3. Requirement: discom DI must not exist at time t : /Di(t).

4. Requirement: the two sibling discoms to be merged, D;(t) and Dj(t) must be children
of discom Dk(t) : (Dk(t) Di(t)) A (Dk(t) Dj(t)).

5. Operation: CSAk,(t + 1) = CSA,~(t) U {(g, Ns (Di, Dj, Di))}.

6. Operation: a new discom, DI is created at time t + 1 with all the members of its tuple
empty: D ( = (Si = 0, 01 = 0, P; = 0, AS1 = 0, R 0 = 0), such that Dk I D1.

7. Operation: Si(t + 2) = S;(t + 1) U Sj(t + 1).

8. Operation: GI(t + 2) = Gi(t + 1) U G(t + 1).

9. Operation: O(t + 2) = O(t + 1) U Oj(t + 1). Since all children discoms are objects
in their parent discom, this means that any children discoms of the two discoms being
merged are automatically merged as well.

10. Operation: Pi(t + 2) = {(k, Di) 3p E Pi(t + 1) U PJ(t + 1), k = II(p)}.

11. Operation: AS(t + 2) = {(s, (p, o)) z| AS;(t + 1) U AS(t + 1), s = IIl(z), p =
( II( HII( H2())), DI), o= H2( 2 (X)) }









12. Operation: Ri(t+ 2) = R(t + 1) U Rj(t + 1).


13. Operation: discoms Di(t + 2) and Dj(t + 2) and any of their contents are deleted:
/3Di(t + 2), /3Dj(t + 2).
14. Operation: CSAk,m(t + 2) = CSAk,m(t + 1) {(g, N (Di, Dj, Di))}.

15. Operation: ARSk(t + 2) = ARSi(t) {(gm ps (Di, Dj, Di))}.
Theorem 8 (Discom Merging Theorem): Ts is secure state preserving.
Proof: Assume that SS(t) E E contains a governor subject (g, e Gk) in the parent
discom Dk of two sibling discoms Di and Dj at time I who requests the merging of the
siblings.
1. Usage property: by lemma 1 from (2), (5), and (14).

2. Creator property:

by (6) a new discom DI(t + 2) is created;
by (1) and (2) DI was created by a governor g, e Gk where Dk I D;;
by (8) gm automatically becomes a governor of Di;

therefore the Creator property holds.

3. Government property: by (11) since Si(t) is secure, then g E GG has access to Di
(likewise for Dj) at time t, then by (8) g E GI, and by (11) g has access to DI(t + 2).
Therefore the Government property holds.

4. Cordon property: a merge of two discoms is a forced intersection which, nevertheless,
does not violate the Cordon property because a single, new discom is created. This is
because Di(t + 2) and Dj(t + 2) are deleted. This means:

V a, a 1, O(t + 2) = O(t + 1) = O,(t) and O,(t) n O(t) = 0 and O,(t) n
Oj(t) = 0 by the assumption that SS(t) is a secure system state, and Oi(t + 2) =
Oi(t) U Oj(t), therefore O(t + 2) n Oi(t + 2) = 0;
a similar argument is used for P;, ASi, and RI because they are all composed of
components from Di and Dj which did not intersect at time t by the assumption
that SS(t) is a secure system state, therefore they don't intersect now;

therefore the Cordon property holds.

5. Nova property: by lemma 5.

6. Demesne property: by lemma 6.

7. Ceiling property: by lemma 7.

8. Sanitation property: by lemma 8.

Q. E. D.








Tg: Discom Splitting Rule


Discom splitting presents the problem that any child discoms of the discom to be split must
be allocated in some way to the new discoms which result from the split (i.e., no child discoms
may be orphaned). Two methods of doing the split were considered (there are others that
were not considered). First, the discom can be split into two sibling discoms. Second, the
discom can be split such that one of the two discoms which result from the split can be made
a child of the other. There seemed no practical reason for the latter, so the former method
was chosen. The rule now follows.
When a governor subject (gs e Gk) in the parent discom Dk of the discom Di to be split
(i.e., Dk Di) requests that Di be split into two discoms Di and Dj at time t then the
following must occur.

1. Requirement: gs(t) must have the "split discom" privilege p9 in its capabilities set:
(/, Dk) E CSk,,(t).
2. Requirement: the access request set ARSk(t) must contain a tuple of the form (g, p9 (Di, Dj))
where Di is the discom to be split, and (Di, Dj) is a tuple of the two discoms that will
result from the split (i.e., the split will result in Dk Di and Dk Dj).

3. Requirement: Di(t) must exist, and must be sired by Dk(t) : Dk(t) Di(t).

4. Operation: CSAk,s(t + 1) = CSAk,s(t) U {(gs, 9 (Di, Dj))}.

5. Operation: a new discom, Dj is created at time t + 1 and is sired by Dk : Dk(t + 1) ,
Dj(t + 1). The elements of the tuple of Dj(t + 1) are initially empty: Dj(t + 1) = (S =
0, Oj = 0, P, = 0, AS, = 0, Rj = 0).
6. Operation: the elements of Si(t) must be split between Si(t + 2) and Sj(t + 2) so that
S,(t) = S,(t + 2) U Sj(t + 2). Note that S(t + 2) n Sj(t + 2) # 0 is permitted, and also
Gi(t) C Si(t + 2) n S(t + 2).
7. Operation: the elements of Oi(t) must be split between O(t + 2) and Oj(t + 2) so that
o0(t) = Oi(t + 2) U Oj(t + 2) and O(t1 + 2) n Oj(t + 2) = 0.
8. Operation: the privileges of Pi(t) must be duplicated among Pi(t + 2) and Pj(t + 2) so
that:

P(t + 2) = P(t);
Pj(t + 2) = {(k, Dj) I k I (Pi(t))}.

9. Operation: the elements of ASi(t) must be duplicated among AS(t + 2) and ASj(t + 2)
so that:

AS,( + 2) = AS(t) {(s, (p, o)) s 3 S,(t + 2) V o O(t + 2)};
AS,(t+2) = {(s, (p, o)) | 3x E AS3(t), s = ni(x)nS2(t+2), p = (II( II( I2())), Dj), o
H2( H2(x)) n 0(t + 2)}.








10. Operation: the elements of Ri(t) must be split between Ri(t + 2) and Rj (t + 2) so that
Ri(t) = R(t + 2) U Rj(t + 2) and Ri(t + 2) n R (t + 2) = 0.

11. Operation: the governors of Di(t) must be duplicated in Di(t + 2) and Dj(t + 2)
Gi(t) = Gi(t + 2) = Gj (t + 2).

12. Operation: CSAk,s(t + 2) = CSAk,,(t + 1) {(9, 9 (Di, Dj))}.

13. Operation: ARSk(t + 2) = ARSk(t)- {(g, p9 (Di, Dj))}.

Theorem 9 (Discom Splitting Theorem): T9 is secure state preserving.
Proof: Assume that SS(t) E E contains a governor subject gs E Gk in the parent discom
Dk of the discom Di to be split requests that Di be split into two discoms Di and Dj at time
t.

1. Usage property: by lemma 1 from (2), (4), and (12).

2. Creator property:

by (2) gs is a governor of Dk;
by (11) gs is a governor of both Di and Dj : gs, Gi, and gs E Gj;

therefore the Creator property holds.

3. Government property: by lemma 3.

4. Cordon property:

the new object sets created from the split set do not intersect with each other nor
with any third object set:
V k i, Oi(t) n Ok(t) = 0;
Oj(t + 2) C Oi(t) therefore Oj(t + 2) n Ok = 0, and the same argument is
used for Oi(t + 2);
by (7) Oi(t + 2) n Oj(t + 2) = 0;
by (8) the privileges of Pi(t) must be duplicated among Pi(t + 2) and Pj(t + 2) so
that:
Pi(t + 2) = Pi(t);
P(t + 2) = {(k, Dj) |k e IIf(P,(t))};
Pi(t + 2) n (t + 2) = 0;
by (9) the action set of ASi(t) must be duplicated among ASi(t+2) and ASy(t+2)
so that:
AS(t + 2) = AS,(t) (s, (p, o)) s ( Si(t + 2) V o } O;(t + 2)};
ASJ(t + 2) = {(s, (p, o)) 3x E AS,(t), s = HII(x) n S,(t + 2), p =
( HII( II( I2(x))), Di), o = H2( H2(x)) n O(t + 2)};








AS,(t + 2) n AS,(t + 2) = 0;
by (10) Ri(t) = R(t + 2) U Rj(t + 2) so Rj(t + 2) C Ri(t), but Ri(t) n R,(t)
0 V a 7 i, and R(t + 2) = R,(t) V a i, j so R,(t+ 2) n Rj(t+ 2) = 0. The
same argument is used for Ri. Therefore also by (10) Ri(t + 2) n Rj(t + 2) = 0;

therefore the Cordon property holds.

5. Nova property: by lemma 5.

6. Demesne property: by (11) the governors of Di(t) must be duplicated in Di(t + 2) and
Dj(t + 2) : Gi(t) = Gi(t + 2) = Gj(t + 2). Therefore the Demesne property holds.

7. Ceiling property: by lemma 7.

8. Sanitation property: by lemma 8.

Q. E. D.

TIO: Empire Destruction Rule
When an oligarch wd in an empire EP consisting of empire discom D3 with no children (i.e.,
'(DE + D) V E E i) requests the destruction of empire E3 at time t, then the following
must occur.

1. Requirement: wd must have the "destroy empire" privilege plo in its capabilities set:
(pio, EP) e CSE,d().
2. Requirement: the access request set ARSi(t) must contain a tuple of the form (Od pio DE).

3. Requirement: the empire discom D'E(t) to be destroyed must rule no other discoms
(i.e., it must have no descendants): -(DjE(t) ,+ D3(t)), V k, k z E.
4. Operation: CSAE,d(t + 1) = CSAE,d(t) U {(wd io DE)}.

5. Operation: the action set AS>(t+1) of discom D'U(t+1) must be emptied: AS>(t+1) =
0.

6. Operation: the subject set S(t + 1) of discom Dj(t + 1) must be emptied: S>(t + 1) =
0.

7. Operation: the privilege set Pi(t+1) of discom D'(t+1) must be emptied: Pi(t+1) =
0.

8. Operation: every object in DE(t + 1) must be emptied by returning the resource of
every object in D'(t) to the system administration from which the resource originated,
in a sanitized state: V(r E oM, o, E OE(t)), ((T(r, t + 1) ) A (r R t + 1)))
This means that Vo OE(t + 1), o(t + 1) = 0.

9. Operation: all the (now empty) objects in OE(t + 2) must be deleted: O(t + 2) = 0.

57









10. Operation: all the members of the tuple of discom D'(t + 3) must be deleted, causing
D'(t + 3), and therefore empire Ej to cease to exist.

11. Operation: CSAE,d(t + 3) = CSAE,d(t + 2) {(w 0io DE)}.

12. Operation: ARSf(t + 2) = ARSf(t) {(wa p0 DE)}.

Theorem 10 (Empire Destruction Theorem): Tio is secure state preserving.
Proof: Assume that SS(t) E E contains an oligarch wd in an empire E5 consisting of
empire discom D' with no children requests the destruction of empire E5 at time t.

1. Usage property: by lemma 1 from (2), (4), and (11).

2. Creator property: by lemma 2.

3. Government property: by lemma 3.

4. Cordon property: by lemma 4.

5. Nova property: by lemma 5.

6. Demesne property: by lemma 6.

7. Ceiling property: by lemma 7.

8. Sanitation property: by (8) all resources from the empire discom to be deleted, DE
must be sanitized before being returned to the system administration from which they
came: V (r(t) e (o, E O(i))) = T(r, t + 1) = o. Therefore the Sanitation property
holds.

Q. E. D.

T71: Empire Merging Rule

There are five ways in which empires can be merged that were considered:

1. a new empire, consisting of only one discom (the empire discom) is created and then
the empires to be merged are made children of the new empire;

2. one of the two empires to be merged is made a child of the empire discom of the other;

3. one of the two empires to be merged is made a child of a leaf discom of the other;

4. one of the two empires is made a child of a non-leaf and non-empire discom of the
other (i.e., inserted in the middle of the tree);

5. the empire discoms are merged into one discom.








The last way was chosen due to its simplicity. The rule follows.
When two oligarch subjects woi E Q' and wc e R' in two empires E' and EJ respectively,
request that the two empires be merged at time t then the following must occur.

1. Requirement: o 6 QE(t) and w~ e R E(t) must have the "merge empires" privilege pn
in their capabilities sets: (pn, E') G CSE',,(t) and (pn, E3) e CSEJ,b(t)) respectively.
2. Requirement: the access request set ARS(t) must contain a tuple of the form (w/ P11 (Ei, E E ))
and the access request st ARS (t) must contain a tuple of the form (Co pn1 (E, E3, Ek)).
(Ei, Ej, Ek) indicates that empires Ei and Ej are to be merged into empire Ek such
that Ek = E' U Ej when the rule has finished.

3. Requirement: empire Ek must not exist at time t : /AEk(t).
4. Operation: CSAE,,A,(t++) =CSAE,,(t) U {(wO Ni1 (Ei, Ej, Ek))} and CSAEb (t+
1)= CSAE,b (t) U {(WO N (E Ej, E ))}.
5. Operation: a new empire, Ek is created at time (t + 2) with all the members of its
tuple empty (i.e., Sk =0, 0' = 0, PE = 0, ASk = 0, R = 0).

6. Operation: S,(t + 2) = S(t + 1) U SE(t + 1).
7. Operation: t (1+ 2) = Q(t + 1) U Q (t + 1).
8. Operation: O (t + 2) = 0 (t + 1) U Oj(t + 1).
9. Operation: P (t + 2) = {(a, D) k 3p E P (t + 1) U P1(t + 1), a= Hi(p)}.
10. Operation: ASki(t+2) = {(s, (p, o)) | 3x G AS(t+ 1) U AS(t+ 1), s= Hi(x), p=
( II( II( 12(X))), Dk), o= H2( 2(x))}.
11. Operation: R( + 2) = R(t+ 1) U R + 1).
12. Operation: CSAE,,,(t+2)= CSAE,,,(t+l)-{(O N (E, Ej, Ek))} and CSAE,bJ(t+
2) = CSAEbJt + 1) {( 11 (Ei, E, E ))}.

13. Operation: ARS%(t + 2) = ARS(t)- {(o p11 (Ei, E Ek))} and ARSf(I + 2) =
ARS(1) {( PE11 (E, Ej, E))}.

Theorem 11 (Empire Merging Theorem): rl is secure state preserving.
Proof: Assume that SS(t) G E contains two oligarch subjects wo E QE and wo e OR in
two empires E' and EJ respectively, who request that the two empires be merged at time t.

1. Usage property: by lemma 1 from (2), (4), and (12).
2. Creator property:

by (5) a new empire discom Dk(t + 2) is created;









by (1) and (2) D I(t + 2) was jointly created by oligarchs wo c ,(t) and w E
Q 3 (t);
by (7) w2 and Jw automatically become oligarchs of D'(t + 2);

therefore the Creator property holds.

3. Government property: by lemma 3.

4. Cordon property: a merge of two empire discoms Dl (t) and D (t) is a forced intersec-
tion which, nevertheless, does not violate the Cordon property because a single, new
empire discom Di(t + 2) is created. This is because D (t + 2) and D3(t + 2) are
deleted. This means:

V a, a 1, O(t + 1) = O(t + 2) = O(t) and O,(t) n O(t) = 0 and O(t) n
O~(t) = 0 by the assumption that SS(t) is a secure system state, and 0E(t +2)
Oc(t) U O~(t), therefore Oa(t + 2) n O(t + 2) = 0;
A similar argument is used for PE, AS}, and Rk because they are all composed of
components from DE and D3 which did not intersect at time t by the assumption
that SS(t) is a secure system state, therefore they don't intersect at time t + 2;

therefore the Cordon property holds.

5. Nova property: by lemma 5.

6. Demesne property: by lemma 6.

7. Ceiling property: by lemma 7.

8. Sanitation property: by lemma 8.

Q. E. D.

712: Empire Splitting Rule
Two ways to split an empire were considered.

1. One subtree of an empire is removed from that empire and made into second empire.
The root node of the second empire becomes the empire discom.

2. The empire discom is split into two new empire discoms, with the resources of that
empire allocated in a manner to be specified by the governors of the empire.

The last way was chosen due to its simplicity.
Subjects are not shared across empires. Two ways of dealing with this were considered.

1. Duplicate (or "clone") the subjects. In this case, the subjects have to "inherit" their
privileges, etc.








2. Partition the subjects in separate empires.


The first way is more difficult to model, while the last way is quite easy to model.
Therefore, the last way was chosen. The rule follows.
When an oligarch subject w~s G QE in the empire E' requests that DE is to be split into
two empires E' and Ej at time t then the following must occur.

1. Requirement: ~s(t) must have the "split empire" privilege p12 in its capabilities set:
(pl2, E') CSE',s(t).
2. Requirement: the access request set ARS%(t) must contain a tuple of the form (w p12 (E', EJ))
where E' is the empire to be split, and E' and E3 are the two empires that will result
from the split.

3. Requirement: E'(t) must exist: 3E'(t).

4. Requirement: EJ(t) must not exist: 3EJ(t).

5. Requirement: I|Ql > 1. The reason for this is that since the subjects are partitioned
in different empires, there should be at least two oligarchs: one for each empire that
results from the split.

6. Operation: CSAE,s(t + 1) = CSAE,s(t) U {(~s N12 (EK, EJ))}.

7. Operation: a new empire, Ej is created at time t + 1 with the elements of its empire
discoms DE initially empty: D = (SE = 0, OE = 0, PE 0, AS = 0, RE = 0).

8. Operation: the elements of S%(t) must be split between S((t + 2) and SE(t + 2) so
that S%(t) = S%(t + 2) U SL(t + 2) and S%(t + 2) n S(t + 2) = 0.

9. Operation: the elements of k0(t) must be split between Ok(t + 2) and O(t + 2) so
that Ok(t) = Ok(t + 2) U OE(t + 2) and Ok(t + 2) n O(t + 2) = 0.

10. Operation: the privileges of PL(t) must be split between PL(t + 2) and Pi(t + 2) so
that:

P(t+ 2)= P ();
SP(t + 2)= {(k, DE) | k e (Pi(t))}.

11. Operation: the elements of ASi(t) must be split between AS(t + 2) and ASE(t + 2)
so that:

AS(t + 2) = AS(t) {(s, (p, o)) |s S%(t + 2) V o Ok(t + 2)};
ASE(t + 2) = {(s, p, o)) x e AS%(t), se Hi(x) n SL(t + 2), p =
H( n H( i(f2(x))), DE), o = nH( 2(x)) n oE(t + 2)}.

12. Operation: the elements of RL(t) must be split between RD(t + 2) and R3(t + 2) so
that R(t) = RE(t + 2) U RE(t + 2) and RZ(t + 2) n R(t + 2) = 0.








13. Operation: the oligarchs QRE(t) of EJ(t) must be split between E(t + 2) and E3(t + 2)
Q(t + 2) P(t) n S(t + 2), Q"(t+ 2) = Q(t) n S(t + 2), and w e Q(t + 2). This
is because subjects do not intersect in empires, therefore QzE(t + 2) n Q3(t + 2) =0.

14. Operation: CSAE,A(t + 2) = CSAE,s(t + 1) {( ,N12 (E, EJ))}.

15. Operation: ARS((t + 2) = ARS(t) {(w p2 (E, EJ))}.

Theorem 12 (Empire Splitting Theorem): T12 is secure state preserving.
Proof: Assume that SS(t) E E contains an oligarch subject (ws E aE) in the empire E'
that requests that De is to be split into two empires E' and EP at time t.

1. Usage property: by lemma 1 from (2), (6), and (14).

2. Creator property: by (13) wa is an oligarch of EK : w EQ therefore the Creator
property holds.

3. Government property: g E GE(t) no longer has access to discoms that do not go to
the same empire as g. However, by (11) and (13) the governors still have appropriate
access in their new empire.

4. Cordon property:

the new object sets created from the split set do not intersect with each other nor
with any third object set:
V k Z i, O (t)n Ok(t) = 0;
o(t + 2) C o~(t) therefore V k ( j, O~(1 + 2) n O~(t + 2) = 0;
O(t + 2) C O~(t) therefore V k i, 0(t + 2) n O(t + 2) = 0;
by (9) O (t + 2) n 0 (t + 2) = 0;
by (9) the privileges of Pc(t) must be duplicated among P,(t + 2) and Pj(t + 2)
so that:
PA (t + 2)= PA (t);
PE(t + 2) = {(k,, D,) ke II(P())};
by (10) the action set of AS(t) is partitioned and thinned between AS{(t + 2)
and AS{(t + 2) so that:
AS(t+2) = AS(t)-{(s, (p, o)) | S S3(t+2), p E P"(t+2), o e O(t+2)};
ASE(t+2) = AS%(t)-{(s, (p, o)) |s e S'(t+2), p e P'(t+2), o e 0e(t+2)};
A (t + 2) n AS (t + 2) = 0;
by (12) R(t) = Ri(t+ 2) U Rj(t + 2) and R(t + 2) n Rj(t + 2) = 0;

therefore the Cordon property holds.

5. Nova property: by lemma 5.









6. Demesne property:

by (13) the oligarchs Q~(t) are split between E(t + 2) and E (t + 2): QP(t)
(t + 2) U Q3,(t + 2);
by (11) and (13) the governors still have appropriate access in their new empire;
if g e ~Q(t) then g had access down by SS(t) e E, if g e Q~ (t + 2) and Dk e Ei
then g still has access by (11), if g e RE(t + 2) and Dk G Ej then g has access by
(11);

therefore the Demesne property holds.

7. Ceiling property: by lemma 7.

8. Sanitation property: by lemma 8.

Q. E. D.

713: Subject Creation Rule
When a creator subject s, in discom Di in empire E3 requests the creation of a new non-
governor subject s, at time t then the following must occur.

1. Requirement: s, must have the "create subject" privilege P13 in its capabilities set:
(/i, (Si, AS,)) e CSi,(t).

2. Requirement: the access request set ARSi(t) must contain a tuple of the form (sC p13 (sc, Si, AS;)).

3. Requirement: s,(t) must not exist: sn, Si(t).

4. Requirement: an object on must exist which will be the new subject's default object:
on eO ().

5. Operation: CSAi,,(t + 1) = CSAi,c(t) U {(sc 13 (Sc, Si, ASi))}.

6. Operation: the new subject's empire, E3 must exist: 3E3.

7. Operation: the new subjects upper discom, Di must exist: 3Di.

8. Operation: the new subject is created at time t + 1 : s,(t + 1) = (Di, EP, o,).

9. Operation: CSAi,,(t + 2) = CSAi,c(t + 1) {(so N13 (sc, Si, ASi))}.

10. Operation: ARSi(t + 2) = ARS(i) {(s, p13 (s8, S, AS,))}.

Theorem 13 (Subject Creation Theorem): -13 is secure state preserving.
Proof: Assume that SS(t) G E contains a creator subject s. in discom Di in empire Ej
who requests the creation of a new non-governor subject s, at time t.








1. Usage property: by lemma 1 from (2), (5), and (9).

2. Creator property: by lemma 2.

3. Government property: by lemma 3.

4. Cordon property: by lemma 4.

5. Nova property: by lemma 5.

6. Demesne property: by lemma 6.

7. Ceiling property: by lemma 7.

8. Sanitation property: by lemma 8.

Q. E. D.


714: Subject Destruction Rule
When a destroyer subject sd in discom Di in empire Ej requests the destruction of a non-
governor subject Sk at time t then the following must occur.

1. Requirement: sd must have the "destroy subject" privilege 1p4 in its capabilities set:
(p14, (Si, ASi)) e CSi,d(t).
2. Requirement: the access request set ARSi(t) must contain a tuple of the form (sd 14 (sk, Si, ASi)).

3. Requirement: Sk(t) must exist: Sk e Si(t).

4. Requirement: Sk(t) must be a leaf in the tree of discoms of which Sk is a subject,
rooted in the upper discom of Sk, that is, it must belong to no descendant discoms of
Di(t) : sk e Si(t) => (sk i Sit) V 1, Di(t) J+ Di(t)).

5. Requirement: Sk(t) must not be accessing any objects in Oi at time t : (sk I; o) 0
ARS,(t) V 1, o.

6. Operation: CSAi,d(t + 1) = CSAi,d(t) U {(sd 14 (Sk, Si, ASi))}.

7. Operation: the destroyer subject sd removes all entries in the action set ASi(t + 1) for
Sk : AS(t + 1) = AS(t) {(sk, (p, o)) | (p, o) e PO(t)}.

8. Operation: the capabilities set for Sk is deleted at time t + 1 : aCSi,k(t + 1).

9. Operation: Sk is deleted: S(t + 1) = Si(t) {sk}.

10. Operation: if Di is the upper discom of Sk, then the default object Ok of sk is deleted
using the object destruction rule T2 resulting in: ok ( Oi(t + 3).

11. Operation: CSAi,d(t + 2) = CSAi,d(t + 1) {(sd 14 (Sk, Si, ASi))}.









12. Operation: ARSi(t + 2) = ARSi(t) {(sd 14 (Sk, Si, ASi))}.

Theorem 14 (Subject Destruction Theorem): T14 is secure state preserving.
Proof: Assume that SS(t) E E contains a destroyer subject sd in discom D, in empire
E5 who requests the destruction of a non-governor subject Sk at time t.

1. Usage property: by lemma 1 from (2), (5), and (11).

2. Creator property: by lemma 2.

3. Government property: by lemma 3.

4. Cordon property: by lemma 4.

5. Nova property: by lemma 5.

6. Demesne property: by lemma 6.

7. Ceiling property: by lemma 7.

8. Sanitation property: by (11) the resources used by the subject are returned by using
the object destruction rule. Therefore the Sanitation property holds.

Q. E. D.

T15: Create New Privilege Rule
When a subject s, wishes to create a new privilege p, in discom Di at time t then the
following must occur.

1. Requirement: sp must have the "create new privil. privilege p15 in its capabilities
set: (pi5, Pi) E CSi,(t).

2. Requirement: the access request set ARSi(t) must contain a tuple of the form (sp p15 (pn, Pi)).

3. Requirement: the new privilege, p, must not exist: pn, Pi(t).

4. Operation: CSAi,p(t + 1) = CSAi,p(t) U {(sp, N5 (pn, Pi)}.

5. Operation: the new privilege is created as a tuple of the form (n, Di) and is added to
the privilege set: Pi(t + 1) = Pi(t) U {p, = (n, Di)}.

6. Operation: the steps of the new rule cannot be specified here, but the new rule must
be proven to be secure state preserving.

7. Operation: all governors must have the new privilege added to their action set: ASi(t+
2) = ASi(t) U {(s, (pa, o)) s Gi(t), O'} where 0' C Oi(t) is all objects to which
p, applies.

8. Operation: CSAi,p(t + 2) = CSAi,p(t + 1) {(s, N5 (pn, Pi))}.









9. Operation: ARSi(t + 2) = ARS (t) {(s, pl (Pn, Pi))}.

Theorem 15 (Create New Privilege Theorem): T15 is secure state preserving.
Proof: Assume that SS(t) E E contains a subject s, who wishes to create a new privilege
p, in discom Di at time t.

1. Usage property: by lemma 1 from (2), (4), and (8).

2. Creator property: by lemma 2.

3. Government property: by (7) all governors must have the new privilege added to their
action set: ASi(t + 2) = ASi(t) U {(s, (pn, o)) s s Gi(t), O'} where 0' C O(t) is all
objects to which p, applies. Therefore the Government property holds.

4. Cordon property:

Oi and Ri are not affected in any way;
by (7) ASi expands only in Di;
by (5), Pi does not intersect any other privilege set: V j P i, Pi(t) n Pj(t) = 0,
and Pj(t + 1) = Pj(t), and because the privilege tuples in the privilege sets
Pi(t + 1) and Pj(t + 1) are different: H2(Pi(t + 1)) H2 (P (t + 1)), therefore
Vj #i Pn P =0,

therefore the Cordon property holds.

5. Nova property: by lemma 5.

6. Demesne property: by lemma 6.

7. Ceiling property: by lemma 7.

8. Sanitation property: by lemma 8.

Q. E. D.

T16: Destroy Non-initial Privilege Rule
When a subject sp wishes to destroy a non-initial privilege p, in discom Di at time t then
the following must occur.

1. Requirement: sp must have the "destroy non-initial privil. privilege p16 in its capa-
bilities set: (p16, Pi) E CS,,p(t).

2. Requirement: the access request set ARSi(t) must contain a tuple of the form (sp p16 (pn, Pi)).

3. Requirement: the privilege to be destroyed, p, must exist: pn, Pi(t).

4. Requirement: the privilege to be destroyed, p, must not be an initial privilege: n > 24.

66









5. Operation: CSAi,,(t + 1) = CSAi,p(t) U {(sp 16( p, Pi))}.

6. Operation: the new privilege is subtracted from the privilege set: Pi(t + 1) = Pi(t) -


7. Operation: the action set ASi must be modified to delete the privilege p, : ASi(t+2)
ASi(t) {(s, (p., o)) se Si(t), o e O(t)}.

8. Operation: CSAi,p(t + 2) = CSA,,(t + 1) {(s 16 (,, Pi))}.

9. Operation: ARS,(t + 2) = ARSi(t) {(s, P16 (p, P))}.

Theorem 16 (Destroy Non-initial Privilege Theorem): T16 is secure state preserving.
Proof: Assume that SS(t) E E contains a subject s, who wishes to destroy a non-initial
privilege p, in discom Di at time t.

1. Usage property: by lemma 1 from (2), (5), and (9).

2. Creator property: by lemma 2.

3. Government property: by lemma 3.

4. Cordon property: by lemma 4.

5. Nova property: by lemma 5.

6. Demesne property: by lemma 6.

7. Ceiling property: by lemma 7.

8. Sanitation property: by lemma 8.

Q. E. D.

T17: Create Governor Rule
When a governor s, wishes to create a new governor subject g, from an existing subject s,
in discom Di at time t then the following must occur.

1. Requirement: s, must be a governor: s, C Gi(t) and will have the "create governor"
privilege p17 in its capabilities set: (p17, Gi) E CS,c(t).

2. Requirement: the access request set ARSi(t) must contain a tuple of the form (sc p17 s8).

3. Requirement: the subject s, to be made a governor must exist: s, E Si(t).

4. Operation: CSAi,,(t + 1) = CSAi,c(t) U {(s, N17 s.)}.

5. Operation: s, must be added to the governor set: Gi(t + 1) = Gi(t) U {s,}.









6. Operation: the privileges of s, must be upgraded (if necessary) to all privileges: ASi(t+
1) = ASi(t) U {(as, (p, o)) (p, o) e CSi,m, sm e Gi(t)}.

7. Operation: the new governor, s,(t + 1) must be added to the subject and governor set
of all descendant discoms of Di : V k, Di(t+ 1) J+ Dk(t+ 1), Gk(t+ 1) = Gk(t) U {s}J,
and Sk(t + 1) = Sk(t) U {s,} by using rule T23 and rule T17 recursively.

8. Operation: CSAi,c(t + 2) = CSAi,c(t + 1) {(s, 17 s,)}.

9. Operation: ARSi(t + 2) = ARSi(t) {(s, P17 s }.

Theorem 17 (Create Governor Theorem): T17 is secure state preserving.
Proof: Assume that SS(t) E E contains a subject s, who wishes to create a new governor
subject g, from and existing subject Sn in discom Di at time t.

1. Usage property: by lemma 1 from (2), (4), and (8).

2. Creator property: by lemma 2.

3. Government property: since (SS(t) E E) = (s, E Gi(t)) and has the necessary privi-
leges, then by (6) so will Sn and therefore the Government property holds.

4. Cordon property: by lemma 4.

5. Nova property: by lemma 5.

6. Demesne property: by (7) the new governor gn may access all descendant discoms of
Di : V k | Di + Dk = ((gn E Gk) A (sn E Sk)). Therefore the Demesne property
holds.

7. Ceiling property: by lemma 7.

8. Sanitation property: by lemma 8.

Q. E. D.

r18: Rescind Governorship Rule
When a rescinder governor g, wishes to rescind the governorship from governor gs in discom
Di at time t then the following must occur.

1. Requirement: g, must have the "rescind governorship" privilege pls in its capabilities
set: (/,,. Gi) CSi,,(t).

2. Requirement: the access request set ARSi(t) must contain a tuple of the form (g, pis gs).

3. Requirement: the governor gs to be made a non-governor must exist: gs Gi(t).

4. Requirement: the governor gs must be at the top of its governor tree: V j Z i, (Dj ,+
Di) 4 (gs Gj).









5. Requirement: the governor set Gi must contain at least two governors at time t, so
that at least one governor remains after gs is rescinded: I|G(t)| > 2. This is required
because it is possible for a governor to rescind governorship from itself, and if we didn't
have this requirement then it would be possible to have governorless discoms.

6. Operation: CSAid(t + 1) = CSAid(t) U {(g,N Rs gs)}.

7. Operation: g, must be subtracted from the governor set: Gi(t + 1) = G() {gs}.

8. Note: it is not necessary to add s, (the subject equivalent to g,(t)) to the subject set
of Di since ss is already a member of it.

9. Operation: CSAi,,(t + 2) = CSAi,,(t + 1) {(g, Nis gs)}.

10. Operation: ARS;(t + 2) = ARS;(t) {(g, pis gs)}.

Theorem 18 (Rescind Governorship Theorem): ris is secure state preserving.
Proof: Assume that SS(t) e E contains a governor g, who wishes to rescind governorship
from governor g, in discom Di at time t.

1. Usage property: by lemma 1 from (2), (6), and (9).

2. Creator property: by lemma 2.

3. Government property: by (1) since g, is a governor, the Government property holds.

4. Cordon property: by lemma 4.

5. Nova property: by (8) the new non-governor s, still retains the ability to access de-
scendant discoms (this can be revoked later if necessary). Therefore the Nova property
is preserved.

6. Demesne property: by (4) the governor that is rescinded is at the top of its governor
tree: V j z i, Dj J+ Di; = g,. Gj. Therefore, by being "trimmed" from only the top
of the tree, the Demesne property holds.

7. Ceiling property: by lemma 7.

8. Sanitation property: by lemma 8.

Q. E. D.








T19: Add Resource to Pool Rule
When a subject s, wishes to add a resource r' to the resource pool R, of discom Di at time
t then the following must occur.

1. Requirement: sp must have the "Add Resource to Pool" privilege pig in its capabilities
set: (p19, Ri) CSi,,(t).

2. Requirement: the access request set ARSi(t) must contain a tuple of the form (sp pg9 (r Ri)).

3. Requirement: the resource r' to be added must originate at time t from one of the
following:

the resource pool Rj of the parent discom Dj of Di : Dj I Di;
the resource pool Rh of a child discom Dh of Di : Di Dh;
a system administration A' : A(r') = A1.

4. Operation: CSAi,,(t + 1) = CSAi,p(t) U {(sp N19 (r R ))}.

5. Operation: the resource r' to be added must be sanitized: T(r', t) = .

6. Operation: the resource must be added to the resource pool Ri(t + 1) of discom Di(t +
1) : R(t + 1) = R(t) U {rl.

7. Operation: the resource rI must be deleted from one of the following where it originated
at time t:

a r is deleted from the resource pool Rj(t + 1) of the parent discom Dj(t + 1) of
Di(t + 1) : (Dj(t + 1) I D~(t + 1)), (Rj(t + 1) = R(t) {r});
a r is deleted from the resource pool Rh(t + 1) of the child discom Dh(t + 1) of
Di(t + 1) : (Di(t + 1) I Dh(t + 1)), (Rh(t + 1) = Rh(t) {rl});
a system administration Al(t + 1), A(r'(t + 1)) = A'(t + 1) which presumably
marks the resource as allocated, in some manner which can not be specified in
this model.

8. Operation: CSAi,,(t + 2) = CSAi,,(t + 1) {(sp 19 (r, R))}.

9. Operation: ARSi(t + 2) = ARSi(t) {(sp p9i (r, Ri))}.

Theorem 19 (Add Resource to Pool Theorem): T19 is secure state preserving.
Proof: Assume that SS(t) G E contains a subject s, who wishes to add a resource r, to
the resource pool R, of discom Di at time t.

1. Usage property: by lemma 1 from (2), (4), and (8).

2. Creator property: by lemma 2.








3. Government property: by lemma 3.

4. Cordon property: O0, Pi, and AS, are not involved, so only Ri is of concern. First,
assuming that a system administration is not involved:

by (6) the resource ra is added to Ri(t + 1);
by (7) the resource ra is deleted from either Rj(t + 1) or Rh(t + 1);
if by (7) r' Rj(t + 1), then Ri(t + 1) n Rj(t + 1) = 0 and the Cordon property
holds;
if by (7) r' Rh(t + 1), then Ri(t + 1) n Rh(t + 1) = 0 and the Cordon property
holds;

lastly, if a system administration is involved, then the Cordon property holds.

5. Nova property: by lemma 5.

6. Demesne property: by lemma 6.

7. Ceiling property: by lemma 7.

8. Sanitation property: by (5) the resource r to be added must be sanitized: T(r=, t) = .
Therefore the Sanitation property holds.

Q. E. D.

T20: Remove Resource from Pool Rule
When a subject s, wishes to remove a resource r' from the resource pool Ri of discom Di
at time t then the following must occur.

1. Requirement: sp must have the "Remove Resource from Pool" privilege p20 in its
capabilities set: (p20, Ri) E CSi,,(t).

2. Requirement: the access request set ARSi(t) must contain a tuple of the form (sp p20 (r Ri)).
3. Requirement: r'(t) must be unused: T(r t) = a.

4. Operation: CSA,,(t + 1) = CSAi,p(t) U {(sp, 20 (r Ri))}.

5. Operation: the resource must be removed from the resource pool Ri(t + 1) of discom
Di(t + 1) : R(t + 1) = R(t) {r}.

6. Operation: the resource r\ must be added to one of the following at time t + 1:

r is added to the resource pool Rj(t + 1) of the parent discom Dj(t + 1) of
D (t + 1) : (D (t + 1) I Di(t + 1)), (R (t + 1) = R (t) U {rl});
r is added to the resource pool Rh(t+1) of the child discom Dh(t+1) of Di(t+ 1)
(Di(t + 1) I Dh(t + 1)), (Rh(t + 1) = Rh(t) U {ra});

71









ra is returned to the system administration that owns it A'(t + 1), A(r (t + 1))
Al(t + 1) which presumably marks the resource as unallocated, in some manner
which can not be specified in this model.

7. Operation: CSAi,,(t + 2) = CSAi,,(t + 1) {(s, 20 (r2 R ))}.

8. Operation: ARS,(t + 2) = ARS,(t) {(s, p20 (r, Ri))}.

Theorem 20 (Remove Resource from Pool Theorem): T20 is secure state preserving.
Proof: Assume that SS(t) E E contains a subject s, who wishes to remove a resource r'
from the resource pool Ri of discom Di at time t.

1. Usage property: by lemma 1 from (2), (4), and (7).

2. Creator property: by lemma 2.

3. Government property: by lemma 3.

4. Cordon property: O0, Pi, and AS; are not involved, so only Ri is of concern. First,
assuming that a system administration is not involved:

by (5) the resource r, is deleted from Ri(t + 1);
by (6) the resource ri added to either Rj(t + 1) or Rh(t + 1);
if by (6) r' E Rj(t + 1), then R;(t + 1) n Rj(t + 1) = 0 and the Cordon property
holds;
if by (6) r' E Rh(t + 1), then R;(t + 1) n Rh(t + 1) = 0 and the Cordon property
holds;

lastly, if a system administration is involved, then the Cordon property holds.

5. Nova property: by lemma 5.

6. Demesne property: by lemma 6.

7. Ceiling property: by lemma 7.

8. Sanitation property: by (3) the resource r' that was removed is sanitized: T(r=, t) = a.
Therefore the Sanitation property holds.

Q. E. D.









T21: Grant Privilege to Subject Rule
When a granter subject s, wishes to grant a new privilege pm to subject s" in discom Di at
time t then the following must occur.

1. Requirement: sp must have the "Grant Privileges to Subject" privilege p21 in its capa-
bilities set: (p21, s~) E CSi,p(t).

2. Requirement: the access request set ARSi(t) must contain a tuple of the form (sp p21 (Pm, Sn)).

3. Requirement: the new privilege, pm must exist: pm E Pi(t).

4. Requirement: the non-granter subject s, must exist: s, e Si(t).

5. Operation: CSAi,,(t + 1) = CSAi,p(t) U {(sp N21 (Pm, Sn))}.

6. Operation: the action set ASi(t + 1) must be modified to include the new subject-
privilege: ASi(t + 1) = ASi(t) U {(s, (pm, o)) o C O(t + 1)}.

7. Operation: CSAi,,(t + 2) = CSAi,p(t + 1) {(sp 21 (p, s,))}.

8. Operation: ARSi(t + 2) = ARSi(t) {(sp p21 (Pm, s8))}.

Theorem 21 (Grant Privilege to Subject Theorem): T21 is secure state preserving.
Proof: Assume that SS(t) E E contains a granter subject sp who wishes to grant a new
privilege pm to subject s, in discom Di at time t.

1. Usage property: by lemma 1 from (2), (5), and (7).

2. Creator property: by lemma 2.

3. Government property: by lemma 3.

4. Cordon property: O0, Pi, and Ri are not affected in any way. By (6), ASi does not
intersect any other action set: V j f i, ASi(t) n ASj(t) = 0, and ASj(t + 1) = ASj(t),
and because the privileges in the action set tuples of ASi(t+1) and ASj(ti) are different:
II( II2(ASi(t + 1))) / IIH( HI2(ASj(t + 1))), therefore V j Z i, AS, n ASj = 0, and
the Cordon property holds.

5. Nova property: by lemma 5.

6. Demesne property: by lemma 6.

7. Ceiling property: by lemma 7.

8. Sanitation property: by lemma 8.

Q. E. D.









T22: Rescind Privilege from Subject Rule
When a rescinder subject s, wishes to rescind a privilege pm from a non-governor subject s"
in discom Di at time t then the following must occur.

1. Requirement: sp must have the "Rescind Privileges from Subject" privilege p22 in its
capabilities set: (p22, s.) E CSi,p(t).

2. Requirement: the access request set ARSi(t) must contain a tuple of the form (s p22 (Pm, Sn)).

3. Requirement: the privilege to be rescinded, pm must exist: pm E Pi(t).

4. Requirement: the non-governor, non-rescinder subject s, must exist: s, E {Si(t) -
G (t)}.
5. Operation: CSAi,,(t + 1) = CSAi,p(t) U {(s, N22 (p,, S))}.

6. Operation: the action set ASi(t + 1) must be modified to remove the rescinded subject-
privilege: ASi(t + 1) = ASi(t) {(s, (pm, o)) o e Oi(t + 1)}.

7. Operation: CSAi,,(t + 2) = CSAi,,(t + 1) {(s, 22 (pm, Sn))}.

8. Operation: ARSi(t + 2) = ARS,(t) {(sp p22 (P, s8))}.

Theorem 22 (Rescind Privilege from Subject Theorem): T22 is secure state preserving.
Proof: Assume that SS(t) E E contains a rescinder subject s, who wishes to rescind a
privilege pm from subject s, in discom Di at time t.

1. Usage property: by lemma 1 from (2), (5), and (7).

2. Creator property: by lemma 2.

3. Government property: by lemma 3.

4. Cordon property: by lemma 4.

5. Nova property: by lemma 5.

6. Demesne property: by lemma 6.

7. Ceiling property: by lemma 7.

8. Sanitation property: by lemma 8.

Q. E. D.









T23: Make Subject Member of Child Discom Rule
When a governor g, in discom Di wishes to make a subject s, in discom Di a member of
discom Dj where Dj is a child of Di at time t then the following must occur.
1. Requirement: g, must have the "Make Subject Member of Child Discom" privilege p23
in its capabilities set: (p23, Sc) e CSi,a(t).

2. Requirement: the access request set ARSi(t) must contain a tuple of the form (g, p23 (Dj, s5)).

3. Requirement: g, must be a governor in discom Di : g, e Gi.

4. Requirement: discom Dj must exist: 3Dj.

5. Requirement: discom Dj must be a child of discom Di : Di Dj.

6. Requirement: subject s, must exist: s, e Si(t).

7. Operation: CSAAi,(t + 1) = CSAi,0(t) U {(g, N23 (Dj, s,))}.

8. Operation: subject s, is added to the subject set of discom Dj : Sj(t+1) = Sj(t)U{sc}.

9. Operation: CSAAi,(t + 2) = CSAi,(t + 1) {(g, 23 (Dj, s,))}.

10. Operation: ARS,(t + 2) = ARSi(t) {(g, P23 (Dj, s,))}.
Theorem 23 (Make Subject Member of Child Discom Theorem): T23 is secure state pre-
serving.
Proof: Assume that SS(t) e E contains a governor g, in discom Di who wishes to make
a subject s, in discom Di a member of discom Dj where Dj is a child of Di at time t.
1. Usage property: by lemma 1 from (2), (7), and (9).

2. Creator property: by lemma 2.

3. Government property: by lemma 3.

4. Cordon property: by lemma 4.

5. Nova property:

by (8) s,, a non-governor, is added to the child discom Dj : s, e Sj(t + 1);
by (1) g, is a governor who is privileged to make s, a member of a child discom:
(p23, Sc) CSG,a(t);
therefore the Nova property holds.

6. Demesne property: by lemma 6.

7. Ceiling property: by lemma 7.

8. Sanitation property: by lemma 8.
Q. E. D.









T24: Remove Subject as Member of Child Discom Rule
When a governor g, in discom Di wishes to remove a subject so in discom Dj where Dj is a
child of Di at time t then the following must occur.
1. Requirement: ga must have the "Remove Subject as Member of Child Discom" privilege
p24 in its capabilities set: (p24, Sc) E CSi,a(t).
2. Requirement: the access request set ARSi(t) must contain a tuple of the form (g, p24 (Dj, s8)).

3. Requirement: ga must be a governor in discom Di : g, E Gi.
4. Requirement: discom Dj(t) must exist: 3Dj(t).

5. Requirement: discom Dj(t) must be a child of discom Di(t) : Di(t) I Dj(t).

6. Requirement: subject so must exist in discom Dj(t) : so E Sj(t).

7. Requirement: subject s, must not be a member of any descendant discoms of Dj(t)
V k, Dj(t) J+ Dkt) => Sc 8 Sk(t).

8. Operation: CSAi,,(t + 1) = CSAi,,(t) U {(g, N24 (Dj, s,))}.

9. Operation: subject so is removed from the subject set of discom Dj : Si(t + 1) =
Si(t) {s}.
10. Operation: the action set ASj(t + 2) must be modified to remove s : ASj(t + 2) =
AS(t) {(s1, (p, o)) I p Pi, o E O}.
11. Operation: CSAi,,(t + 2) = CSAi,,(t + 1) {(g, N24 (Dj, s,))}.

12. Operation: ARSi(t + 2) = ARS,(t) {(g, p24 (Dj, s())}.
Theorem 24 (Make Subject Member of Child Discom Theorem): T24 is secure state pre-
serving.
Proof: Assume that SS(t) E E contains a governor g, in discom Di who wishes to make
a subject so in discom Di a member of discom Dj where Dj is a child of Di at time t.
1. Usage property: by lemma 1 from (2), (8), and (11).

2. Creator property: by lemma 2.

3. Government property: by lemma 3.

4. Cordon property: by lemma 4.

5. Nova property: by lemma 5.

6. Demesne property: by lemma 6.

7. Ceiling property: by lemma 7.

8. Sanitation property: by lemma 8.
Q. E. D.









T25: Empire Creation Rule


An empire is created through an act of some system administrationss, outside of this model.
In accordance with the genesis axiom, the initial system state, SS(to), must be assumed to
be a secure system state. The initial creation of an empire consists only of a single empire
discom with one governor subject, only one default object for the governor subject, an initial
set of privileges, an empty action set, and some pool of resources allocated by the system
administrations involved in the creation of the empire:

Ej = (Di, +),

where
DE = (S = W OE= {ol}, PJ = {p, p2,..., P24}, AS= 0, RE).


4.3 Aftermath

The approach used in the construction of this model follows that of a formal security policy
model, such as BLP [6]. A set of model components are defined, then a group of secure state
invariants, and finally a set of rules are presented and proven to transform one secure system
state into another secure system state. This was all done to model formally the security
policy presented in chapter three. Of course, this model does not solve every problem that
might occur in a distributed system, but it does provide a general mechanism for coping
with unexpected situations due to the fact that new privileges can be added and secure rules
created for those new privileges.
Some particularly interesting issues came up during the construction of the model, such
as the various ways in which discoms can be merged and split, and the many ways in which
empires can be split. Generally, whenever a variety of ways of implementing a rule existed,
the simplest way was chosen (e.g., for the rescind governorship rule, it is required that there
be at least two governors in the discom, although the model could support governorless
discoms). This does not mean that the other, more complicated ways should not be explored
in the future, along with other variations of the model. In addition, a profound difference
between how subjects are destroyed, and governors are rescinded manifested itself: subjects
must be removed from the "bottom" and governors must be rescinded from the "top." A
thorough discussion of the model follows in the next chapter.













Chapter 5


DISCUSSION OF THE

DISTRIBUTED COMPARTMENT

MODEL



5.1 Introduction
This chapter contains five main sections. First, there is a brief discussion of the similari-
ties and differences between the standard model and BLP. Next, some alternatives to the
standard Distributed Compartment Model are presented. Then some implementation issues
are discussed. Next, some example scenarios are given that will help illustrate the use of an
implementation of the standard Distributed Compartment Model. Finally, some ideas for
future research are included.

5.2 Comparison of the Distributed Compartment Model
to BLP

5.2.1 Introduction
Since BLP had such a profound influence on the construction of the Distributed Compart-
ment Model, a brief mention of the similarities and differences between the two models seems
appropriate. Appendix B is provided as a convenience for the reader who is not familiar with
BLP.

5.2.2 Similarities
Both the Distributed Compartment Model and BLP are examples of formal security policy
models. Both have a set of model components (or "elements" as BLP refers to them) that
give a descriptive capability to the models. Also, both have a set of rules and theorems (or
"general mechanisms" in BLP parlance).









Each model contains both discretionary and non-discretionary (i.e., mandatory) access
controls. In BLP, the discretionary controls are in the form of an access matrix, while in the
Distributed Compartment Model they are in the form of an action set that is isomorphic to
an access matrix. In BLP, the non-discretionary controls are embodied in the simple-security
property and the *-property, while in the Distributed Compartment Model they are in the
11 secure state invariants.
Both models are state-transition models, representing the way in which the system tran-
sits from one secure state to another, by way of rules. Both models have theorems, proving
that the rules do not violate the secure state invariants.
In many respects BLP is the quintessential formal security policy model, and therefore
will share many of the above similarities with many other formal security policy models.


5.2.3 Differences

The differences between BLP and the Distributed Compartment Model are considerable.
While both are very similar in the sense of being formal security policy models, BLP is not
especially concerned with the way resources are allocated and managed, and it is certainly not
concerned with separate system administrations interacting, which is no surprise considering
that distributed systems were not their focus. BLP has no provisions for the labeling of
subjects (in the sense of handles), while the Distributed Compartment Model does not
assign any sort of security clearance level to subjects, or security classification to objects.
Additionally, BLP is not particularly concerned with the organization of subjects and
objects within administrative boundaries (e.g., via discoms). While BLP is very concerned
with the security categories of subjects and objects, this is not at all similar to the idea of
a distributed compartment.


5.2.4 Conclusions

While the two models are similar in the sense that they are formal security policy models,
their security policies are very dissimilar. This is certainly a result of the fact that the driving
force behind the construction of the Distributed Compartment Model is that distributed
systems are in wide use. In 1976, when BLP was finished, distributed systems were quite rare.
In fact, Bell and LaPadula mention that their model does not even have to be implemented
on a computer, and that it has even been used in non-computer security applications [6].
It seems difficult to envision the use of the Distributed Compartment Model without a
computer system.
Interestingly, it seems possible that BLP could be implemented as a specific security
policy within a particular discom. This flexibility is not present in BLP. As noted in chapter
two, systems that tried to strictly implement BLP encountered numerous problems. It
remains to be seen if this will be the case with the Distributed Compartment Model, since
an implementation of it does not yet exist.









5.3 Alternatives to the Standard Distributed Com-
partment Model

5.3.1 Introduction
These alternatives to the standard Distributed Compartment Model were experiments done
to I -.-- ,I:" one of the attributes of the standard model and to see what would result. There
are endless variations of the Standard Model, so this process could go on forever. However,
the experimentation was limited to the variations that follow.
In the theorems and corollaries that follow, the numbering scheme used is designed to
allow easy reference to both the model, and theorem or corollary. All the models have their
own independent numbering system (e.g., the first theorem in all the models starts with the
number 1). A subscript indicates the model (e.g., 12 indicates theorem 1 in model 2). This
was done for mnemonic reasons. For convenience, the Standard Model does not use this
convention.

5.3.2 Second Model
Introduction
The second model is identical to the Standard Model with the exception that the governs
relation has been modified so that it is no longer antisymmetric, but is, instead, symmetric.

Differences from the Standard Model
Since the governs relation is now symmetric, for two subjects a, b:

(a b) = (b4 a).

The lack of antisymmetry means that the governs relation no longer forms a lattice
because it now contains cycles due to the fact that all the governors of a discom now form
a clique (i.e., a fully connected graph).
Since the governs relation is still reflexive and transitive, the change from antisymmetry
to symmetry means it is now an equivalence relation among the governors. However, there
is only one equivalence class, which is the clique of governors.

Theorems
Theorem 12 If an oligarch exists, all subjects are governors: V s e S, s e Gi.
Proof: (V s e S,, V g e Gi) = (g 4 s). By symmetry (g 4 s) = (s 4 g) therefore s e Gi.
Q. E. D.

Theorem 22 All governors are oligarchs: (s e S ) ( (s G QJ).
Proof: ((Qf # 0) A (a G QJ) A (b e GJ)) = (a 4 b), therefore b 4 a (by symmetry).
(b 4 a) 4 (b e Q).









Q. E. D.


Corollary 12 All governors have the empire discom as their upper discom: since (s e
Si) = (s e Q) (by Theorem 2.2) and since IIl(w) = DE then IIl(s) = DE.

Corollary 22 All subjects belong to every discom: (s G QJ) = (s G Si, V Si; Sj) by the
Demesne property.

Failure of the Second Model

The above shows that the second model is not practical, since every subject is a member
of every discom in an empire, and every subject has the maximum privileges possible in an
empire. This is obviously unacceptable.


5.3.3 Third Model

Introduction

The third model is identical to the first model with the exception that the governs relation
has been modified so that it is no longer antisymmetric, but is, instead asymmetric.

Differences from the Standard Model

Making the governs relation asymmetric instead of antisymmetric has some profound conse-
quences regarding the ability of a subject or a governor to govern itself, as theorem 13 which
now follows, will show.
Theorem 13 No governor or subject can govern itself: -(a 4 b) V (a = b).
Proof: Since the governs relation is now asymmetric, for two subjects a and b : (a 4 b) =
-(b 4 a). This means that a governor or subject can not govern itself: -(a 4 a) V (a e S).

Failure of the Third Model

It makes no sense to say that "a governor can not govern itself," because a governor woul not
be allowed to modify any of its privileges, thus violating the twenty-second initial privilege
that all governors must have (rescinding privileges from a subject).
In addition, since the governs relation is now asymmetric, there is now a partial ordering
on all subjects (not a lattice, however), with at least one maximal element (a governor),
and maybe more than one maximal element. In this model, "governors" either must have
restricted rights (i.e., not be able to govern all others in a discom), or there can only be one
governor.
Because of the above two points, the second model does not seem practical.









5.3.4 Fourth Model


Introduction

The fourth model was constructed as an experiment with the principle of -. p.! ration of pow-
ers." That is, for certain privileges, it would require not one subject, but multiple subjects in
order to exercise the privilege. This is a very common situation in many circumstances (e.g.,
banking applications, military command and control), and it was thought that a variation
of the Standard Model that allowed for the separation of powers principle might be useful.

Differences from the Standard Model

The Fourth Model is identical to the First Model with the exception that the governs relation
has been modified so that it is no longer antisymmetric, but is, instead asymmetric. In
addition, if a and b are governors, then trusted subjects ab and b, are automatically created
that serve to validate the actions of one governor regarding another governor:

((a e GC) A (b e GC)) = (a 4 b) iff ((Eab G S,) A (ab 4 b)).

Since the governs relation is no longer antisymmetric, this means that it no longer forms
a lattice. However, this does not appear to present a problem.

Analysis of the Fourth Model

Time did not permit a thorough exploration of the fourth model, since it could easily turn
into a major research project. However, it looks promising, and it may turn out to be a
viable alternative to the Standard Model.


5.3.5 Fifth Model

The fifth model eliminates the Demesne property, and thereby allows governorship to be
revokable for descendant discoms. This means that a governor could revoke all rights he
might have to any or all descendant discoms. This would be valuable for many applications,
however, it carries the danger that if a governor revokes his governorship from any discom,
then that discom is completely autonomous from that governor. This means that if the
governor were to later wish access, he would have to get it from one of the existing governors
of the autonomous discom. If they refused to give it to him, his only recourse would be to
appeal to the system administrations involved.
This model shows promise and we hope it is going to be one of the main areas of future
research.


5.3.6 Conclusions

The above alternatives to the Standard Model were interesting experiments that, in the cases
of the second and third model, helped to verify that the Standard Model's construction of
the governs relation was correct. The fourth and fifth models look like promising avenues
for future research.









In addition, there are even more variations possible that were not explored in any detail.
For example, in the sixth model, there is the concept of a "real" governor who can pass a
"scepter" on to another subject called a "vi,. .. who could then exercise some of the powers
of the governor (however, a viceroy could not affect other governors or other viceroys). In
the seventh model, governors in the same discom are allowed to govern each other. It seems
that the Standard Model lends itself particularly well to variations. This implies that it is
flexible, which is a desirable trait for a model of this type to have.


5.4 Implementation Issues

5.4.1 Introduction

The Distributed Compartment Model was created with the viewpoint of eventually designing
and implementing a software version of the model. Implementing the model as a software
system would help point out good and bad areas of the model and lead to further refinement
of the model in an iterative fashion.


5.4.2 Software Design

A software design that would be used to implement the model could take many forms. The
most important criterion is that the software system be verifiable regarding the model (i.e.,
that we can verify that the software system actually implements the model without any
violations of the model). The most likely scenario is as follows.
The administration of security in a discom would be done by using a client-server model.
Discom servers would be available for each discom that is created, and would act as proxies
for the operating system users who actually own the administrative resources being used.
When a subject wishes access to a discom, a client process would be invoked that would
then contact the discom servers. The discom servers would manage access control using
the subject's distributed handle, and then manage the security privileges of that subject.
All access of objects in a discom by a subject would take place through the discom's proxy
servers. Access would not be allowed through the normal operating system methods.
A special server, called the world name server, would be available at a well-known location
(this server might be replicated and distributed across several systems). This server would
maintain a list of all empire discoms and all distributed handles. It would be responsible for
insuring that all empire discom names and all distributed handles were unique, by providing
the names used and distinguishing among them. The convention for naming any individual
discom could be similar to the idea of a file pathname, however, in this case we could call it
a discompath. This would consist of a unique path from the empire discom to the particular
discom being used, with discoms delimited by the symbol '/'. For example, a discompath
might be 'greenwald/research/papers'. A subject currently accessing a discom need only
refer to the current discom by the simple name of that discom (e.g., 'research'), as is done
in a traditional operating system such as UNIX.
Each discom server would probably keep at least the following information.









DiscomID This is a unique identifying label for the discom.

Physical Locations This is a list of the hosts and directories that comprise the discom.

Discom Level This is the depth of the discom in the tree structure. Level 0 would indicate
that the discom is an empire discom.

Parent Discom This is the discomlD of the parent discom, or null for an empire discom.

Sibling Discoms This is a list of all discoms that have the same parent as this discom.

Child Discoms This is a list of all children discoms.

Governors This is a list of all the governors and their distributed handles of the discom.

Subjects This is a list of all the subjects and their distributed handles of the discom.

Objects This is a list of all the objects of the discom.

Privileges This is a list of all the privileges of the discom.

Action Set This is the action set of the discom.

Resources This is the resource pool of the discom.

As the model is refined and the software design progresses, it is presumed that the above
will be revised.


5.4.3 Software Implementation

It is difficult to discuss the details of implementation without going through the design phase
first, but it seems that prototyping might be the best method for the construction of the
software system that implements the model. The major advantage of this approach is that
as changes are made to the model or software specification, they can be rapidly incorporated
in the software. The main disadvantage is that somewhat more effort will be needed to
construct the software in the first place, and it may be necessary to dispose of the first
prototyped version of the software after the model is finalized, and then construct a new
version.
Alternately, an argument can be made that if the Distributed Compartment Model is
well defined, it can serve as the basis for an architectural design document, and therefore
more traditional software engineering methods can be used to implement the model.


5.5 Usage Examples

In order to better clarify the ideas presented here, the following example usage scenarios are
given. All labels are given in uppercase for clarity.









5.5.1 Electronic Mail Between Discoms


One common application is electronic mail. In order to exchange electronic mail between
discoms (or any other type of information) a subject would be used as an intermediary. Of
course, the subject would have to be a member of both discoms. It could read the mail from
one discom, and act as an information flow conduit while writing to the other discom. Of
course, the subject would need to have the necessary privileges in order to accomplish this.

5.5.2 "Simple" File Creation

A file is called "simple" if the resources from which it is composed come from only one
administration. A file would be composed of one or more objects in a particular discom.
Each object would contain only resources from the same administration. The resources
involved might be blocks of disk storage.

5.5.3 "Complex" File Creation
A file is called comply :: if the resources from which it is composed come from more than one
administration. Such a file would be composed of one or more objects in a particular discom.
The resources of these objects would come from more than one administration. This would
amount to sharing the file across multiple system administration boundaries. The resources
involved might be blocks of disk storage from the different system administrations involved.

5.5.4 Replicated Fault Tolerant Files

Replicated fault tolerant files are possible within a discom by making several files that do
not share resources from the same system administration. For example, if there were two
files, each an object: o, and ob in a particular discom, information stored in them could be
duplexed (i.e., the two files would always contain the same data under ideal circumstances).
However, to implement a replicated fault tolerant file structure across system administration
boundaries, we would add the constraint that the two files must not contain resources from
administrations in common with each other: A(o) n A(ob) = 0. This would be an extremely
easy way to implement replicated fault tolerant files across administrative boundaries, with
a high degree of fault tolerance since the two files do not share any resources in common
from the same administrations.

5.5.5 CPU Resource Access
In the Distributed Compartment Model, resources can be allocations of Central Processing
Unit (CPU) time. For example, a particular resource r might represent up to 10 seconds
of CPU time of supercomputer access (if less than 10 seconds were used, all of the resource
would be expended since resources are atomic in this model). An object incorporating r
could use up that resource depending on the actions of the subject who controls the object.
This is an example of an expendable resource.









5.5.6 Distributed Conferencing

A groupware system such as the Distributed Conferencing System (DCS) [33] is designed to
facilitate group work. Such a system can be used for conferencing where the participants
are not physically present in the same location. It would be useful for each conference to
have associated with it one (or more) discoms in which objects could reside, and in which
distributed handles could be used to identify the conference participants by roles. The
handles for particular roles need not change in different discoms (and hence conferences).
For example, consider two conferences named "THEORY-EXAM" and "REFEREE."
Each conference holds regular meetings with the participants (subjects) using DCS, who do
not meet face to face. Each conference is an application running in its own discom, and each
discom has its own set of distributed handles.
In the THEORY-EXAM conference, members are concerned with creating, administering,
and grading one subject area of a Ph.D. comprehensive examination given periodically in
a computer science department. Professor Ada Algol is a subject that maps to the handle
"CHAIRPERSON." She also has certain privileges associated with this subject/handle (for
example, controlling the floor-passing mechanism of certain DCS applications). It is clear
from her handle what role she is playing (although the mnemonic value of the handle may
not be required).
The members of the REFEREE conference are concerned with evaluating papers sub-
mitted to a journal. All the members are anonymous referees for the journal. Professor
Bert Basic is a subject given the handle "CHAIRPERSON." He also has certain privileges
associated with this subject/handle. In this case however, his identity remains a secret due
to the sensitive nature of the task the conference is performing.
In both conferences there exist two handles with the same label (and the same mnemonic
value), yet used by different subjects and unique to their respective discoms. Additionally,
as time goes on and as duties rotate, it is easy to change the identity of CHAIRPERSON to
another member.
In addition, Professor Bert Basic may be a member of the THEORY-EXAM confer-
ence with the handle "BERT," and also a member of the REFEREE conference with the
anonymous handle "REFEREE-3."


5.5.7 Grading Projects

A typical problem is that of a professor who assigns a programming project to students that
is due by a specified date. One of the problems is how the students can submit their program
code in a secure way, without other students having access to it, but allowing the graders
easy access. Currently, in the UNIX environments in common use in academia, the following
are some of the methods used for on-line submission.

1. The graders allow execute access for everyone to directories created for each student
in the graders' own directory tree. But the graders keep the names of the specific
directories hidden from everyone but the particular student. By allowing execute access
but not read access, it unlikely that someone will stumble upon the name (but not
impossible).









2. The graders have each student create a special directory in the student's home directory.
The system administration then creates a special group to which the only members
are the graders. The student must allow group access to the directory. The student
places his files in the directory and they are read by the graders.

3. A special "setuid" program is created that, when invoked by the students will copy
their programs to a directory owned by the graders.

All of these methods are unsatisfactory for a variety of reasons. They are potentially
insecure, rely on the system administration, are cumbersome, or even potentially dangerous
(in the case of using a setuid program).
Using distributed compartments and distributed handles, the graders could create a dis-
com called "PROJECTS" to which only the graders have access. Subdiscoms could then be
created in PROJECTS with each student a subject with their own handle (e.g., "GREEN-
WALD"). Each student would be allowed membership to his own discom, but would be
prohibited from access to any other discom in PROJECTS. Students could then be given
the necessary privileges to read and write to their own discoms during the submission period.
Due to the Creator property, the graders would automatically be governors of discom
PROJECTS. Due to the Cordon property, the students would be prohibited from accessing
each other's discoms as long as the privileges were properly maintained. Students would not
be allowed access above their own discom. Since the graders are governors of the PROJECTS
discom, the Demesne property allows them unrestricted access to all descendant discoms,
and therefore the student's discoms. When the submission period expires, the graders can
simply revoke the students privileges to their discoms, and thereby prohibit late submissions.
All of this would take place in a secure environment, and with no intervention required
from the system administration.


5.5.8 Paper Collaboration

Two researchers at separate universities with separate system administrations might want
to cooperate on the same paper. The researchers might want access to materials at each
other's locations (e.g., source code, word processing files, etc.). Some of the current ways to
do this in a UNIX environment follow.

1. Use File Transfer Protocol (FTP) to periodically exchange files. The researchers would
have to arrange this with their respective system administrations, and could not operate
in real-time.

2. Use electronic mail to send versions of the files back and forth. If the files are binary,
they would have to be uuencoded and uudecoded (uuencoding is a method for ex-
changing binary data over text systems, such as electronic mail, that prohibit certain
control characters). Again, they could not operate in real-time.

3. Petition the system administrations at the respective sites for accounts for the foreign
researchers, and the creation of a security group to which they could both belong.









4. Use miscellaneous dangerous methods (because they give too many privileges to the
collaborators) such as modifications to their ".rhosts" file in certain network environ-
ments. This is effectively the same as sharing accounts.

These methods are not particularly satisfactory for obvious reasons. However, using
distributed compartments and handles, one of the researchers could create a distributed
compartment and make the other researcher a subject (or even a governor), with access
using distributed handles through a proxy server.


5.5.9 Location Transparency

A traveling businessman for a large corporation with many branch offices might need to have
access to his "home" computer system while visiting the different branches. If the computer
systems at the various branches are separately administered, but connected by a computer
network, this would require him to have multiple userIDs and passwords, so that he could
access his home system via the network.
One solution to this problem is to have a guest userID at each location with the same
userID and password, restricted to the group of users who travel around. Normally this is a
bad practice, because historically, guest accounts have been abused. However, this account
can be made with severely limited privileges, allowing access only to the client process that
manages the distributed handle and distributed compartment system over the network
The businessman needs only to remember one userID and password, and can use his
distributed handle to gain access to the distributed compartments that are required.


5.6 Future Research

There is still some interesting research left to do with the Distributed Compartment Model.
For example, as noted earlier, a refinement of models four and five would be a very valuable
experiment.
In the current model, in order for a subject to release access from an object, it need only
delete a tuple from its current subject access set (CSA). If might be a valuable addition to
future models if an explicit revocation mechanism were added to the model. This would be
useful because it would allow a subject that is currently accessing an object to 1.111. -'" to
not access the object any longer. This is analogous to a request in a traditional operating
system that an open file be closed. While the current model can theoretically do this, it
might be more convenient and flexible to have an explicit mechanism that performs this
function.
In addition, it probably would be a useful addition to the model to provide rule templates
for certain types of generic accesses, such as the equivalents to opening a file, closing a file, etc.
As it stands now, the model is most concerned with a framework for resource allocation and
access control, and not the specific types of resources and accesses being used, so providing
these generic templates could prove to be quite useful for an implementation of the model.
An exploration of the boundaries of the Distributed Compartment Model would be valu-
able. For example, there are many intuitive arguments regarding "security" that many









people make, and this also applies to the Distributed Compartment Model. Some of the
possible reasonable and unreasonable properties and accesses that might be explored could
include at least the following.

1. If a subject has exclusive access to a particular resource, then no one else can have
access to it inside or outside the confines of the model.

2. A property could be added so that no one outside the Distributed Compartment
Model's system (even a system administrator) could access the model's system.

3. A property could be added so that no one could infer the contents of one resource from
any other resource's contents.

4. A statement could be added and proven so that no one within the confines of the
model's system and not a member of a particular discom can ever gain access to that
discom.

5. A list of possible attacks that can be made on the model's system and why they would
fail within the boundaries of the system could be made. These attack examples could
be inspired by some of the above intuitive definitions of security that people have, and
would be useful. Some example attacks could be as follows.

A statistical inference attack on a database management system [22], [36], [35],
[42].
A TEMPEST type attack. Carrol, in his book on computer security [8] says that
"the unclassified codeword TEMPEST was used to describe the defense against
undesired signal data ei,.i,,.l i.; i,- [8, page 221]. This type of attack is usually
made by monitoring the radio frequency band electromagnetic radiation emanat-
ing from the hardware of a computer system and making inferences about the
state of the system from those emanations.
A covert storage channel attack [32].
A covert timing channel attack [32].
A cracker who is a member of one discom, gaining unauthorized access to another
discom of which he is not a subject.
Interception of keystrokes over a computer network, to obtain passwords or user
interface information [15].


5.7 Conclusions

BLP was compared to the Standard Model, and the two models were found to be quite
different, even though they share many traits in common. The alternatives to the standard
Distributed Compartment Model varied from interesting failures to some that showed great
promise. We hope that the actual implementation of the Standard Model will help it to









refine further. The example scenarios given are certainly useful as a "reality check" during
the implementation. Finally, the ideas for future research deserve to be explored.
The next chapter mentions some interesting results from the model development process
and concludes this technical report.















Chapter 6



CONCLUSIONS



We wish to stress that the Distributed Compartment Model is modeled in a very general
way at present, for the purpose of finding the problems and deficiencies of the current resource
management and access control methods in groupware environments. This was exactly the
task we set out to accomplish.
We believe that the current Distributed Compartment Model is the beginning of the
evolution of a new paradigm towards a system of resource allocation and access control that
will better meet the needs of distributed computer systems and groupware applications for
many different types of systems. A software implementation of this model will further refine
these ideas.
We have encountered objections to this model (usually from system administrators) on
the grounds that it would allow unscrupulous users to give their resources to any number of
other users, leading to abuse of computer system resources. However, this situation already
exists in current operating systems (for example, it is unfortunately common for users to give
their userID and passwords to other people, thus allowing them access to their accounts). We
feel that in an implementation of this model, better control over resources is possible, since
it would be relatively easy for an individual user to give highly controlled access to resources
in the form of discoms to another user without compromising the security of the existing
systems. In other words, it is possible to limit the rights of users, within the context of the
Distributed Compartment Model, so that in a worst case scenario (such as an unscrupulous
oligarch) no damage can be done to the system outside of the empire to which that user
belongs.
There are many results that have emerged from this model that show how the problem
we set out to tackle has been solved. After much work, the following results from the model
follow.

1. Distributed handles do not have to exist for users alone. Any entity that needs to
access or modify discom objects can have an associated subject and handle. Daemons,
data transformations, probes, processes, etc., can be accommodated by the model.

2. This model does not have to be centralized (and should not be). It can be implemented
in a distributed fashion. The world name server proposed in the implementation section
can be distributed among several computer systems. Each security manager for a









discom can also have a list of associated handles used for communication with other
security managers in a distributed fashion. Duplication of handles is not an issue as
long as the same world name server is used.

3. Security that is compartmentalized and multilevel is possible with this model. Each
subject could have associated with it a group of discoms of which it is a member.
User-defined privileges would allow subject-object access to agree with many different
security policies, with a different policy possible for each discom. For example, BLP
could be implemented in one discom, while a less restrictive version of it could be
implemented in another.

4. Since this model is distributed, fault tolerance can be added by using replicated data
base methods. This should be particularly easy to implement (see the usage example
in the previous chapter).

5. A particular discom can span multiple system administrations if the objects in that
discom are composed of resources from those system administrations.

6. The initial oligarchs of an empire would probably come from the users who provide
resources from their particular system administrations in order to create their empire
discom.

7. A system administration can participate in more than one empire.

8. Objects can be contained by a set of system administrations (i.e., objects can span
system administrations).

9. Discoms can be contained by a set of system administrations.

10. Empires can be contained by a set of system administrations.

11. While network authentication and privacy is not a part of the model, it should be rela-
tively easy to incorporate encryption methods, such as the Data Encryption Standard
(DES) or Public Key systems that can be used for communication between the clients
and servers and for mass storage systems. Digital signatures could also be easily used
in the same manner.

12. Perhaps the most important point of all is that this system frees the user from a large
amount of dependence on various system administrations, while simultaneously freeing
the various system administrations from many tedious tasks. This point will become
increasingly important as distributed systems continue to multiply.


Acknowledgements

We would like to thank the Software Engineering Research Center (SERC) for partially
funding this work. We would also like to thank Captain Marvin Greenwald, USN (retired)
for his valuable comments regarding rule 18 in the standard model, where he pointed out that









because of the Demesne principle, a governor must always be able to rescind the governorship
of a governor in a descendant discom.













Appendix A


MATHEMATICAL

NOMENCLATURE


This appendix is an overview of the various ideas and nomenclature needed for understanding
the basic terminology and mathematics of the models. Almost all of it is basic to the field
of computer science, and is provided as a convenience to the reader.

A.1 Set Notation
For two sets, A and B we can define the following terms.

Size IAI means the number of elements in A.
Equality (A = B) (A C B A B C A).
Union (A U B) {x I x A V x B}.
Intersection (A n B) {x I x E A A x e B}.
Difference (A B) {x I x A A x B}.
Cartesian Product The set of ordered pairs (A x B) {(a, b) a A A b e B}.
Power Set 2A is the set of all subsets of A {SS S A}.

A.2 Relations
If R is a relation and S is the domain set then we can define the following terms [21].

Reflexive aRa V a e S.
Irreflexive -(aRa) V a e S.
Transitive (aRb A bRc) = aRc.




University of Florida Home Page
© 2004 - 2010 University of Florida George A. Smathers Libraries.
All rights reserved.

Acceptable Use, Copyright, and Disclaimer Statement
Last updated October 10, 2010 - - mvs