PROTECTION AND CONTROL
OF
INFORMATION SHARING IN MULTICS
by
Jerome H. Saltzer
Massachusetts Institute of Technology
Department of Electrical Engineering and Project MAC
ABSTRACT
This paper describes the design of mechanisms to control sharing of Information in the Multics system.
Seven design principles help provide insight into the tradeoffs among different possible designs. The key
mechanisms described include access control lists, hierarchical control of access specifications, identifi-
cation and authentication of users, and primary memory protection. The paper ends with a discussion of
several known weaknesses in the current protection mechanism design.
An essential part of a general-purpose computer
utility system is a set of protection mechanisms
which control the transfer of information among the
users of the utility. The Multics system*, a proto-
type computer utility, serves as a useful case
study of the protection mechanisms needed to permit
controlled sharing of information in an on-line,
general-purpose, information-storing system. This
paper provides a survey of the various techniques
currently used in Multics to provide controlled
sharing, user authentication, inter-user isolation,
supervisor-user protection, user-written proprie-
tary programs, and control of special privileges.
Controlled sharing of information was a goal
in the initial specifications of Multics[8, 11],
and thus has influenced every stage of the system
design, starting with the hardware modifications to
the General Electric 635 computer which produced
the original GE 645 base for Multics. As a result,
information protection is more thoroughly inte-
grated into the basic design of Multics than is the
case for those commercial systems whose original
specifications did not include comprehensive con-
sideration of information protection.
Multics is an evolving system, so any case
study must be a snapshot taken at some specific
time. The time chosen for this snapshot is
summer, 1973, at which time Multics is operating
at M.I.T. using the Honeywell 6180 computer system.
Rather than trying to document every detail of a
changing environment, this paper concentrates on
the protection strategy of Multics, with the goal
of communicating those ideas which can be applied
or adapted to other operating systems.
________________________
This research was supported by the Advanced Research
Projects Agency of the Department of Defense under
ARPA Order No. 2095 which was monitored by ONR
Contract No. NOQ014-70-A-0362-0006.
* A brief description of Multics, and a more com-
plete bibliography, are given in the paper by
Corbató, Saltzer, and Clingen[6].
1
What is new?
In trying to identify the ideas related to
protection which were first introduced by Multics,
a certain amount of confusion occurs. The design
was initially laid out in 1964-1967, and ideas
were borrowed from many sources and embellished,
and new ideas were added. Since then, the system
has been available for study to many other system
designers, who have in turn borrowed and embellished
upon the ideas they found in Multics while construc-
ting their own systems. Thus some of the ideas
reported here have already appeared in the litera-
ture. Of the ideas reported here, the following
seem to be both novel and previously unreported:
- The notion of designing a comprehensive com-
puter utility with Information protection as
a fundamental objective.
- Operation of the supervisor under the same
hardware constraints as user programs, under
descriptor control and in the same address
space as the user.
- Facilities for user-constructed protected
subsystems.
- An access control system applicable to batch
as well as on-line jobs.
- Extensive human engineering of the user authen-
tication (password) interface.
- Decentralization of administrative control of
the protection mechanisms.
- Ability to allow or revoke access with
immediate effect.
Multics is unique in the extent to which infor-
mation protection has been permitted to influence
the entire system design. By describing the range
of protection ideas embedded in Multics, the ex-
tent of this influence should become apparent.
Design Principles
Before proceeding, it is useful to review
several design principles which were used in the
development of facilities for information protec-
tion in Multics. These design principles provided
This document was originally prepared off-line. This file
is the result of scan, OCR, and manual touchup, starting
with an original paper copy dated August 10, 1973.
This is the author's original version of the paper. A revised version was published in Communications
of the ACM 17, 7 (July 1974) pages 388-402. http://doi.acm.org/10.1145/361011.361067
guidance in many decisions, although admittedly
some of the principles were articulated only
during the design, rather than in advance.
1. Every designer should know and understand the
protection objectives of the system. At the
present rather shaky stage of understanding of
operating system engineering, there are many
points at which an apparently "don't care"
decision actually has a bearing on protection.
Although these decisions will eventually come
to light as the system design is integrated, a
system design cannot withstand very many rever-
sals of early design decisions if it is to be
completed on a reasonable schedule and within
a budget. By keeping all designers aware of
the protection objectives, the early decisions
are more likely to be made correctly.
2. Keep the design as simple and small as possible.
This principle is stated so often that it be-
comes tiresome to hear. However, it bears
repeating with respect to protection mechanisms,
since there is a special problem: design and
implementation errors which result in unwanted
access paths will not be immediately noticed
during routine use, since routine use usually
does not include attempts to utilize improper
access paths. Therefore, techniques such as
complete, line-by-line auditing of the protec-
tion mechanisms are necessary; for such
techniques to be successful, a small and simple
design is essential.
3. Protection mechanisms should be based on per-
mission rather than exclusion. This principle
means that the default situation is lack of
access, and the protection scheme provides
selective permission for specific purposes.
The alternative, in which mechanisms attempt
to screen off sections of an otherwise open
system, seems to present the wrong psychologi-
cal base for secure system design. A conser-
vative design must be based on arguments on
why objects should be accessible, rather than
on why they should not; in a large system some
objects will be inadequately considered and a
default of lack of access is more fail-safe.
Along the same line of reasoning, a design or
implementation mistake in a mechanism which
gives explicit permission tends to fail by re-
fusing permission, a safe situation, since it
will be quickly detected. On the other hand
a design or implementation mistake in a
mechanism which explicitly excludes access
tends to fail by not excluding access, a fail-
ure which may go unnoticed.
4. Every access to every object must be checked
for authority. This principle, when applied
methodically, is the primary underpinning of
the protection system. It forces a system-
wide view of access control which includes
initialization, recovery, shutdown, and main-
tenance. It also implies that a foolproof
method of identifying the source of every re-
quest must be devised. In a system designed
to operate continuously, this principle re-
quires thai when access decisions are remem-
bered for future use, careful consideration
be given to how changes in authority are pro-
pagated into such local memories.
2
5. The design is not secret. The mechanisms do
not depend on the ignorance of potential
attackers, but rather on possession of speci-
fic, more easily protected, protection keys or
passwords. This strong decoupling between pro-
tection mechanisms and protection keys permits
the mechanisms to be reviewed and examined by
as many competent authorities as possible,
without concern that such review may itself
compromise the safeguards. Peters[19] and
Baran[2] discuss this point further.
6. The principle of least privilege. Every pro-
gram and every privileged user of the system
should operate using the least amount of privi-
lege necessary to complete the job. If this
principle is followed, the effect of accidents
is reduced. Also, if a question related to
misuse of a privilege occurs, the number of
programs which must be audited is minimized.
Put another way, if one has a mechanism avail-
able which can provide "firewalls", the prin-
ciple of least privilege provides a rationale
for where to install the firewalls.
7. Make sure that the design encourages correct
behavior in the users, operators, and admin-
istrators of the system. Experience with
systems which did not follow this principle
revealed numerous examples in which users ig-
nored or bypassed protection mechanisms for
the sake of convenience. It is essential that
the human interface be designed for natural-
ness, ease of use, and simplicity, so that
users will routinely and automatically apply
the protection mechanisms.
The application of these seven design principles
will be evident in many of the specific mechanisms
described in this paper.
Finally, in the design of Multics there were
two additional functional objectives worth dwelling
upon. The first of these was to provide the option
of complete decentralization of the administration
of protection specifications. If the system design
forces all administrative decisions (e.g., protec-
tion specifications) to be set by a single adminis-
trator, that administrator quickly becomes a bottle-
neck and an impediment to effective use of the
system, with the result that users begin adopting
habits which bypass the administrator, often com-
promising protection in the bargain. Even if re-
sponsibility can be distributed among several ad-
ministrators, the same effects may occur. Only by
permitting the individual user some control of his
own administrative environment can one insist that
he take responsibility for his work. Of course,
centralization of authority should be available as
an option. It is easy to limit decentralization;
it seems harder to adapt a centralized design to
an environment in which decentralization is needed.
The second additional functional objective
was to assume that some users will require protec-
tion schemes not anticipated in the original design.
This objective requires that the system provide a
complete set of handholds so that the user, without
exercising special privileges, may construct a pro-
tection environment which can interpret access re-
quests however he desires. The method used is to
permit any user to construct a protected subsystem,
which is a collection of programs and data with
the property that the data may be accessed
only by programs in the subsystem, and the programs
may be entered only at designated entry points. A
protected subsystem can thus be used to program
any desired access control scheme.
The Storage System and Access Control Lists
The central fixture of Multics is an organized
information storage system.[8] Since the storage
system provides both reliability and protection
from unauthorized information release, the user is
thereby encouraged to make it the repository of all
of his programs and data files. All use of infor-
mation in the storage system is implemented by
mapping the information into the virtual memory of
some Multics process. Physical storage location is
automatically determined by activity. As a result,
the storage system is also used for all system data
bases and tables, including those related to protec-
tion. The consequence of these observations is that
one access control mechanism, that of the storage
system, handles almost all of the protection
responsibility in Multics.
Storage is logically organized in separately
named data storage segments, each of which contains
up to 262,144 36-bit words. A segment is the cata-
loguing unit of the storage system, and it is also
the unit of separate protection. Associated with
each segment is an access control list, an open-
ended list of names of users who are permitted to
reference the segment*. To understand the struc-
ture of the access control list, first consider
that every access to a stored segment is actually
made by a Multics process. Associated with each
process is an unforgeable character string identi-
fier, assigned to the process when it was created.
In its simplest form, this identifier might consist
of the personal name of the individual responsible
for the actions of the process. (This responsible
person is commonly called the principal, and the
identifier the principal identifier.) Whenever
the process attempts to access a segment or other
object catalogued by the storage system, the prin-
cipal identifier of the process is compared with
those appearing on the access control list of the
object; if any match is found access is granted.
Actually Multics uses a more flexible scheme
which facilitates granting access to groups of
users, not all of whose members are known, and
which may have dynamically varying membership. A
principal identifier in Multics consists of several
parts; each part of the identifier corresponds to
an independent, exhaustive partition of all users
into named groups. At present, the standard
Multics principal identifier contains three parts,
corresponding to three partitions:
1. The first partition places every individual
user of the installation in a separate access
control group by himself, and names the group
with his personal name. (This partition is
identical to Lhe simple mechanism of the
previous paragraph.)
2. The second partition places users in groups
called projects, which are basically sets of
users who cooperate in some activity such as
constructing a compiler or updating an
________________________
* The Multics access control list corresponds
roughly to a column of Lampson's protection
matrix. [16]
3
inventory file. One person may be a member of
several projects, although at the beginning of
any instance of his use of Multics he must de-
cide under which project he is operating.
3. The third partition allows an individual user
to create his own, named protection compart-
ments. Private compartments are chiefly use-
ful for the user who has borrowed a program
which he has not audited, and wishes to insure
that the borrowed program does not access cer-
tain of his own files. The user may designate
which of his own partitions he wishes to use
at the time he authenticates his identity*.
Although the precise description in terms of
exhaustive partitions sounds formidable, in practice
a relatively easy-to-use mechanism results. For
example, the user named "Jones" working on the pro-
ject named "Inventory" and designating the personal
compartment named "a" would be assigned the princi-
pal identifier:
Jones.Inventory.a
Whenever his process attempts to access an object
catalogued by the storage system, this three part
principal identifier is first compared with succes-
sive entries of the access control list for the
object. An access control list entry similarly has
three parts, but with the additional convention
that any or all of the parts may carry a special
flag to indicate "don't care" for that particular
parLition. (We represent the special flag with an
asterisk in the following examples.) Thus, the
access control list entry
Jones.Inventory.a
would permit access to exactly the principal of our
earlier example. The access control list entry
Jones.*.*
would permit access to Jones no matter what project
he is operating under, and independent of his per-
sonally designated compartment. Finally, the access
control list entry
*.Inventory.*
would permit access to all users of the "Inventory"
project. Matching is on a part by part basis, so
there is no confusion if there happens to be a
project named "Jones".
Using multi-component principal identifiers it
is straightforward to implement a variety of stan-
dard security mechanisms. For example, the military
"need-to-know" list corresponds to a series or
access control list entries with explicit user names
but (possibly) asterisks in the remaining fields.
The standard government security compartments are
examples of additional partitions, and would be
implemented by extending the principal identifier
to four or more parts, each additional part corres-
ponding to one compartment in use at a particular
installation. (Every person would be either in or
out of each such compartment.) A restriction of
access to users who are simultaneously in two or
more compartments is then easily expressed.
________________________
* The third partition has not yet been completely
implemented. The current system uses the third
partition only to distinguish between interactive
and absentee use of the system.
We have used the term "object" to describe the
entities catalogued by the storage system with the
intent of implying that segments are not the only
kinds of objects. Currently, four kinds of objects
are implemented or envisioned:
1. Segments
2. Message queues (experimental implementation)
3. Directories (called catalogues in some systems)
4. Removable media descriptors (not yet imple-
mented)
For each object, there are several separately
controllable modes of access to the object. For
example, a segment may be read, written, or exe-
cuted as a procedure. If we use letters r, w,
and e for these three modes of access, an access
control list entry fur a segment may specify any of
the combinations of access in table I. Certain
access mode combinations are prohibited either be-
cause they make no sense (e.g. write only) or cor-
rect implementation requires more sophisticated
machinery than implied by the simple mode settings.
(For example, an execute-only mode, while appealing
as a method for obtaining proprietary procedures,
leaves unsolved certain problems of general pro-
prietary procedures, such as protection of return
points of calls to other procedures. The protec-
tion ring mechanism described later is used in
Multics to implement proprietary procedures. The
execute-only mode, while probably useful for less
general cases, has not been pursued.)
___________________________________________________
Mode | Typical use
(none) | access denied
r | read-only data
re | pure procedure
rw | writeable data
rew | impure procedure
Table I: Acceptable combinations of access
modes for a segment.
__________________________________________________
In a similar way, message queues permit sepa-
rate control of enqueueing and dequeueing of
messages, tape reel media descriptors permit
separate control of reading, writing, and appending
to the end of a tape reel, and directories permit
separate control of listing of contents, modifying
existing entries, and adding new entries. Control
of these various forms of access to objects is pro-
vided by extending each access control list entry
Co Include access mode indicators. Thus, the access
control list entry
Smith.*.* rw
permits Smith to read and write the data segment
associated with the entry.
It would have been simpler to associate an
access mode with the object itself, rather than
with each individual access control list entry, but
the flexibility of allowing different users to have
different access modes seems useful. It also makes
possible exceptions to the granting of access to
all members of a group. In the case where more
than one access control list entry applies, with
different access modes, the convention is made that
the first access control list entry which matches
4
the principal identifier of the requesting process
is the one which applies. Thus, the pair of access
control list entries:
Smith.Inventory.* (none)
*.Inventory.* rw
would deny access to Smith, while permitting all
other members of the "Inventory" project to read
and write the segment*. To insure that such con-
trol is effective, when an entry is added to an
access control list, it is sorted into the list
according to how specific the entry is by the fol-
lowing rule: all entries containing specific names
in the first part are placed before those with
"don't cares" in the first part. Each of those
subgroups is then similarly ordered according to
the second part, and so on. The purpose of this
sorting is to allow very specific additions to an
access control list to tend to take precedence over
previously existing (perhaps by default) less
specific entries, without requiring that the user
master a language which permits him arbitrary
ordering of entries. The result is that most com-
mon access control intentions are handled correctly
automatically, and only unusually sophisticated
intentions require careful analysis by the user to
get them to come out right.
To minimize the explicit attention which a
user must give to setting access control lists,
every directory contains an "initial access control
list". Whenever a new object is created in that
directory, the contents of the initial access con-
trol list are copied into the access control list
of the newly created object**. Only if the user
wishes access to be handled differently than this
does he have to take explicit action. Permission
to modify a directory's contents implies also
permission to modify its initial access control
list.
The access control list mechanism illustrates
an interesting subtlety. One might consider pro-
viding, as a convenience, checking of new access
control list entries at the time they are made, for
example to warn a user that he has just created an
access control list entry for a non-existent person.
Such checks were initially implemented in Multics,
________________________
* This feature violates design principle three,
which proscribes selective exclusion from an other-
wise open environment because of the risk of un-
detected errors. The feature has been provided
nevertheless, because the alternative of listing
every user except the few excluded seems clumsy.
** An earlier version of Multics did not copy the
initial access control list, but instead considered
it to be a common appendix to every access control
list in that directory. That strategy made auto-
matic sorting of access control list entries in-
effective, so sorting was left to the user. As a
result, the net effect of a single change to the
common appendix couLd be different for every object
in the directory, leading to frequent mistakes and
confusion, in violation of the seventh design prin-
ciple. Since in the protection area, it is essen-
tial that a user be able to easily understand the
consequences of an action, this apparently more
flexible design was abandoned in favor of the less
flexible but more understandable one.
but it was quickly noticed that they represented a
kind of compromise of privacy: by creating an
access control list entry naming an individual, the
presence or absence of an error message would tell
whether or not that individual was a registered
user of the system, thereby possibly compromising
his privacy. For this reason, a name-encoding
scheme which required checking of access control
entry names at the time they were created was
abandoned.
It is also interesting to compare the Multics
access control scheme with that of the earlier CTSS
system[6]. In CTSS, each file had a set of access
restriction bits, applying to all users. Sharing
of files was accomplished by permitting other users
to place in their directories special entries
called links, which named the original file, and
typically contained further restrictions on allow-
able access modes. The CTSS scheme had several de-
fects not present in the Multics arrangement:
1. Once a link was in place there was no way to
remove it without modifying the borrower's
directory. Thus, revocation of access was
awkward.
2. A single user, using the same file via differ-
ent links, could have different access privi-
leges, depending un which link he used.
Allowing access rights to depend on the name
which happens to be used for an object cer-
tainly introduced an extra degree of flexi-
bility, but this flexibility more often re-
sulted in mistakes than in usefulness.
3. As part of a protection audit, one would like
to be able to obtain a list of all users who
can access a file. To construct that list,
on CTSS, one had to search every directory in
the system to make a list of links. Thus such
an audit was expensive and also compromised
other users' privacy.
Multics retains the concept of a link as a naming
convenience, but the Multics link confers no access
privileges -- it is only an indirect address.
Early in the design of Multic«[8] an additional
extension was proposed for an access control list
entry: the "trap" extension, consisting of a one-
bit flag and the name of a procedure. The idea
was that for all users whose principal identifier
matched with that entry, if the trap flag were on
the procedure named in the trap extension should
be called before access be granted. The procedure,
supplied by the setter of the access control list
entry, could supply arbitrary access constraints,
such as permitting access only during certain hours
or only after asking another logged in user for an
OK. This idea, like that of the execute-only pro-
cedure, is appealing but requires an astonishing
amount of supporting mechanism. The trap proce-
dure cannot be run in the requesting user's address-
ing and protection environment, since he is in con-
trol of the environment and could easily subvert
the trap procedure. Since the trap procedure is
supplied by another user, it cannot be run in the
supervisor's protection environment, either, so a
separate, protected subsystem environment is called
for. Since the current Multics protected subsystem
scheme allows a subsystem to have access to all of
its user's files, implementation of the trap exten-
sion could expose a user to unexpected threats from
trap procedures on any data segment he touches.
5
Therefore, at the least, a user should be able to
request that he be denied access to objects pro-
tected by trap extensions, rather than be subject
to unexpected threats from trap procedures. Finally,
if such a trap occurs on every read or write refer-
ence to the segment, the cost would seem to be high.
On the other hand, if the trap occurs only at the
time the segment is mapped into a user's address
space*, then design principle four, that every
reference be validated, is violated; revocation of
access becomes difficult especially if the system
is operated continuously for long periods. The sum
total of these considerations led to temporarily
abandoning the idea of the trap extension, perhaps
until such time as a more general domain scheme,
such as that suggested by Schroeder[21] is
available.
Both backup copying of segments (for reliabil-
ity) and bulk input and output to printers, etc.
are carried out by operator-controlled processes
which are subject to access control just as are
ordinary users. Thus a user can insure that print-
ed copies of a segment are not accidentally made,
by failing to provide an access control list entry
which permits the printer process to read the
segment**. Access control list entries permitting
backup and bulk I/O are usually part of the default
initial access control list. Bulk input of cards
is accomplished by an operator process which reads
them into a system directory, and leaves a note for
the user in question to move them to his own
directory. This strategy guarantees that there is
no way in which one user can overwrite another
user's segment by submitting a spurious card input
request. These mechanisms are examples of the
fourth design principle: every access to every
object is checked for authority.
An administrative consequence of the access
control list organization is that personal and pro-
ject names, once assigned, cannot easily be reused,
since the names may appear in access control lists.
In principle, a system administrator could, when a
user departs, unregister him and then examine every
access control list of the storage system for in-
stances of that name, and delete them. The system
has been deliberately designed to discourage such
a strategy, on the basis that a system administrator
should not routinely paw through all the directories
of all system users. Thus, the alternative scheme
was adopted, requiring all user names, once regis-
tered, to be permanent.
Finally, the one most apparent limitation of
the scheme as presently implemented is its "one-
way" control of access. With the described access
control list organization, the owner of a segment
has complete control over who may access it. There
are some cases in which users other than the owner
may wish to see access restricted to an object
which the owner has declared public. For example,
an instructor of a class may for pedagogical pur-
poses wish to require his students to write a
–––––––––––––––––––––––
* Or, in traditional file systems, at the time the
file is "opened".
** Of course, another user who has permission to
read the segment could make a copy and then have
the copy printed. Methods of constraining even
users who have permission are the subject of con-
tinuing research[20].