From: David Coleman (David.Coleman_at_roxio.com)
Date: Wed Jan 07 2004 - 16:22:21 PST
The paper Protection and the Control of Information Sharing in Multics
by Jerome Saltzer is a fairly in-depth look at the protection mechanisms
in Multics. This paper is not an overview of Multics and does not
provide much discussion even of the storage system that is being
protected. Because of this focus, an overview of Multics might make
digesting the content of this paper easier.
The paper is basically broken up into the following sections:
Introduction, Access Control Lists, Hierarchical Access Control, User
Authentication, Virtual Memory Protection, and Weaknesses.
The overall design principles are an interesting discussion on the
philosophy of secure designs. These same principles are being trumpeted
today (by a large, Redmond-based company) as the correct approach to
building secure software. Reading this section really caused me to
reflect and realize that our industry does not usually look to academic
research when designing or building software. Had these principles been
followed more strictly, our personal computing environments today would
be much more secure than they currently are.
The access control lists (ACL) used in Multics are incredibly flexible.
An ACL is a list of principal identifiers. A principal identifier is a
unique name (often the name of the user) of a process. ACLs were
partitioned into 3 parts: basically user, group/project, and a unique
concept called compartments. The compartment concept seems very useful
as it provides a way to sandbox new programs to keep them from touching
any other storage objects on the system. This capability could be
extended to be very useful today to prevent rogue installation programs
from corrupting systems.
Overlapping ACL entries are allowed and have an algorithm that
determines which one is applied. The algorithm boils down to the most
specific ACL entry being applied. I believe this approach may lead to
some weaknesses in the system due to unintentional overlapping entries
granting or revoking access that the owner did not intend.
Access modes (read, write, execute) are appended to ACL entries
extending their usefulness. This allows owners to grant a group read
access and individual members of that group write access as well.
Additionally functionality included supporting links, (early on, but
later removed) traps where a procedure is run prior to granting access,
dealing with backup copying of segments, printers, etc. One interesting
note is that actual text string names are used in the ACL instead of a
unique user ID which led to some side effects of names never being
removed/reused on the system.
User authentication was probably the largest hole in the security of the
system. Simple passwords were allowed and suggested to the users. The
encryption used on passwords was not strong. As such, the system would
be very susceptible to a dictionary attack. Electing to simply use the
text username instead of a unique user ID again limited the ability to
reuse names. Anonymous logins were allowed but were still subject to
ACL entries. Thus a storage system object had to explicitly allow
anonymous access. All jobs were associated with a user that had to
interactively log in. Even though a chain of batch processes could run,
they had to initiate with a validated user. Proxy jobs were allowed
where the principal identifier of another user is allowed (only after
explicitly granting those rights). Hiding passwords as they are typed
in, displaying last login times, time-outs at terminals were techniques
used to make the user authentication system more usable and more robust.
Virtual memory is protected via hardware support using a
descriptor-based approach. The protection is actually quite elaborate
and even helps to protect against privileged users running amok. The
ability to restrict calls into protected memory to run through certain
entry points prevents intentional misuse as well as programmatic errors
that might compromise the system. Rings of protection (0-7) are
implemented in which the hardware allows a protected subsystem to use
only descriptors of a ring of greater than or the current value. All
memory accesses use the virtual memory system which prevents "backdoor"
access from a non-compliant program.
The discussion of weaknesses is interesting and shows how insightful the
designers really are about the topic of security.
Overall the protection mechanisms in Multics were incredibly well
thought out with particular attention paid, at least indirectly, to
customer needs (such as the DoD). This is somewhat amazing given the
relative lack of security threats that existed when the system was
designed. The Multics team did benefit from hardware support and took
full use of it. Today's PC's do not have the same level of support
which ironically means that they are going to be less secure than
Multics was 30+ years ago.
This archive was generated by hypermail 2.1.6 : Wed Jan 07 2004 - 16:19:47 PST