From: Ian King (iking_at_killthewabbit.org)
Date: Wed Jan 07 2004 - 00:38:43 PST
Saltzer describes the mechanisms designed into the Multics operating system for
the purpose of allowing data to be protected from unauthorized access and use.
The Multics system was "evolving", to use Saltzer's description; therefore, some
of the mechanisms described in this paper are not in fact implemented.
Nonetheless, this paper demonstrates considerable thought from several
perspectives on issues of security for a system used by persons who may be
naive, ignorant or malicious.
Saltzer separately discusses the manner in which access is controlled, and the
mechanism to identify those who seek access. On the first subject, general
principles are first set forth, including the principles of 'deny unless
allowed' and 'least privilege'. It is argued both are superior to alternatives
because of their 'fail safe' nature: if access is not explicitly allowed, the
default is no access, thus protecting data; and if programs are not granted
broad privileges, flaws in the programs are less likely to overstep the
privilege for which they are intended. Open design is another principle, which
forces attention to the true strength of the mechanism rather than relying on
obfuscation. The principle of evaluating privilege on every access to an object
is where the Multics design demonstrates true paranoia, although the argument is
well taken, and is revisited later from the perspective of residual data (on a
storage device or in memory). Finally, the human factor is addressed, briefly
as a general principle, but is revisited several times in depth in specific
features.
The description of access control lists is quite in-depth, and while
acknowledging that it is not truly universal, the compromises made are seemingly
insignificant in actual usage. The scheme is designed both for rigor and for
ease of use; the goal is to create a 'comfortable default' so that users will
naturally apply maximum protection to their data. The permanence of user names
is another feature intended to preclude 'stupid' errors, i.e. accidentally
providing access to a new employee simply because his name is the same as that
of a former employee - one must be astounded at the thought processes involved
in generating the considered scenarios, ranging from the careless to the
devious.
The section discussing authentication is likewise very detailed; however, as
there is little innovative here, the detail is somewhat tedious, although again
one observes the considerable thought that derived scenarios discussed. In
particular, in the discussion regarding the requirement of an authenticated user
for every process (whether directly or through a chain of authority), one may
infer a somewhat military model of responsibility being mapped onto the
operation of the system: SOMEone must accept responsibility, even if the
underlying process is an unattended batch.
The description of protection of in-memory data is interesting, because this
remains a challenge even today; although the hardware for per-process memory
protection exists, poor programming (either in the application, or in the tools
used to produce the application, i.e. the compiler and libraries) can often
subvert that protection.
The honesty with which the author describes the system's weaknesses supports the
credibility to the premises set forth earlier in the paper, especially as each
can be clearly traced to the principles of the system being incorrectly or
incompletely applied. In particular, while ease of use was a key goal, the
richness of the protection mechanisms, together with their interaction with
common computing tasks (e.g. backups), created a system that required
considerable user sophistication. Defaulted choices provided some relief, but
even simple matters such as whether an item of data can be printed require
decisions with possibly broad implications. He also speaks honestly of
economics and schedule pressures as factors in the deficiencies - a factor often
seen in commercial software of all eras.
Finally, Saltzer makes the critical point that the goal of these mechanisms is
to create a securable system; he asserts that no system is secure without
thought to the application of the provided mechanisms toward the user's security
goals. The human is still the arbiter of what it means to be secure.
This archive was generated by hypermail 2.1.6 : Wed Jan 07 2004 - 00:43:35 PST