From: Cliff Schmidt (cliff_at_bea.com)
Date: Wed Jan 07 2004 - 11:15:01 PST
This paper describes the principles, design, experiences, and weaknesses
of the protection aspects (what is today typically referred to as security)
of MIT's Multics operating system. The interesting thing about this paper
to me was how the same issues are still being discussed today as the
industry has tended to put more focus on security in the last few years.
Here are some specific notes:
Design Principle #3: "The design is not secret". Saltzer's claims that
"the mechanisms should not depend on the ignorance of the potential
attackers" and "mechanisms should be examined by many reviewers,
without concern that such review itself may compromise the safeguards".
This sounds to me like the discussions that take place today about
whether open source software is inherently less secure or more secure.
Design Principle #4: "The principle of least privilege". This is another
principle that has typically not been followed to the detriment of today's
security. The problem I've observed is that application developers are
often administrator's on their machines and write code that occasionally
takes advantage of this elevated access (usually unintentionally). By the
time the issue is noticed, it is usually too expensive to fix, requiring
the application to ship with the requirement that certain functions require
the user to be a member of an admin group. As Saltzer points out later in
the paper, when a system admin has too much access, he becomes a target for
traps; conversely, a user should be allowed to run an application with
the lowest possible privilege to escape being prone to high-impact attacks.
One theme that I appreciated was that ease of use and decentralization
of configuration were necessary to encourage users to properly use the
system, as opposed to finding ways to work around the protection system to
get work done.
The principle identifier is made up of three parts: user name, project
groups, and compartments. Project groups sounded like a means of role-
based access. I wasn't able to think of as close an analog to compartments
within a Windows-based server, although it sounded like a reasonable
feature. One note about the syntax for the principle identification: it
wasn't clear how a user of multiple projects or compartments would be
represented syntactically.
It was interesting to note Saltzer's concern about compromising privacy
of user names in validation of ACLs. The same issue could just as easily
apply to email servers that bounce back messages to unknown local names.
Saltzer also brings up topics such as delegation (when he describes
proxies), controlling output echo when the user types their password
(I especially liked the concern for awkward scenarios involving a user
shielding his password from his management), and storage residues,
especially the problem with secondary storage residue, which remains a
problem today.
This archive was generated by hypermail 2.1.6 : Wed Jan 07 2004 - 11:15:06 PST