From: Richard Jackson (richja_at_expedia.com)
Date: Wed Jan 07 2004 - 16:10:10 PST
This paper gives a detailed overview of the various protection features
and design details that were included in a mid-1973 version of the
Multics operating system. The paper is very detailed, and deserves a
careful and slow read.
The 5 key parts of the paper are:
1 - Design Principles.
The author gives a great overview of the underlying design principles,
which are echoed throughout the paper. These concepts are not
surprising(to some extent, they are common sense), and I think they are
quite good. They are: 1) protection via permission rather than
exclusion, 2) check every access to every object, 3) do not depend on
security via obfuscation, 4) give each user only the minimum privilege
necessary, 5) good interface design. While generally I agree with these
concepts, I must question #4. While this theory is good, I think that
the excessive management of these privileges will outweigh the gain. I
found this to be a similar theme throughout the paper. That is,
features that are needlessly complex and overkill for the user's needs.
To be fair, the author accounts for this, noting that a few portions of
the system were scaled back and/or removed to increase usability.
Finally, I must say that I believe #5(above) is the key to this system,
for exactly the reason he gives - "so that users will routinely and
automatically apply the protection mechanisms."
2 - Storage System and Access Control Lists (and separately,
Hierarchical Control of Access Specifications)
A large section was devoted to describing the various organizations to
which a user may belong. These are: personal, project, and
compartments. Of these, the value of compartments seemed questionable to
me, but the implementation gives the opportunity to forgo this
functionality if needed. Also, the use of groups seemed to somewhat
violate basic principle #1, but I also see that this is a tradeoff for
ease-of-use.
In his discussion of access control lists, the ideas seemed very
intuitive. However, I was concerned by the interface for saving these
changes. He indicated that order was critical, but I was worried that
some inconsistency may be possible. The details were lacking, so this
may not be a valid concern.
At the end of this section, the author notes that simplicity was valued
above all other concerns.
The overall concept here seemed similar to the UNIX permission scheme,
though the Multics scheme seems more complex.
3 - User Authentication
This section described a fairly straightforward means of authenticating
users. The underlying design here is sound, and I liked the fact that
all processes must be authenticated before performing an action on the
system. I found it interesting that the author freely admits the
insecurity of the password scheme, and describes how it can easily be
defeated.
4 - Memory protection (using descriptor scheme)
This section gave a good overview of the virtual memory system and a
concept called 'descriptors.' Again, the design is quite good, with
clear separation and protection between the user and privileged portions
of the system. I was most impressed at the way descriptors were used
generically, even recursively within the virtual memory system itself.
5 - Weaknesses/Conclusion
The author presented a variety of system weaknesses, which is admirable
and somewhat unusual. The information listed here provided an
alternate, perhaps slightly less optimistic, view of the system. While
reading prior parts of the paper, it is easy to start thinking that the
system does not have any flaws.
The author also dismissed the concern of performance loss due to high
protection. While a short explanation was provided, I was not convinced
that performance concerns are really a non-issue. Certainly, this could
be quantified in much more detail, though the author claims that such an
experiment would be very difficult.
The major strengths of this paper are:
1) Excellent overview of Multics protection system.
2) Good discussion of drawbacks and flaws in the system
3) Good information about other possible implementations and/or
features that were considered(or removed)
4) Quality design principles, which could be used for many other
related and unrelated systems
The weaknesses of this paper are:
1) While the system is versatile, I think it may be too complex for some
users. I think the author attempts to minimize this concern, but did
not convince me.
This archive was generated by hypermail 2.1.6 : Wed Jan 07 2004 - 16:25:28 PST