“30 Years Later: Lessons from the Multics Security Evaluation”, 2002-12-09 (; similar):
Almost 30 years ago a vulnerability assessment of Multics identified large vulnerabilities, despite the fact that Multics was more secure than other contemporary (and current) computer systems. Considerably more important than any of the individual design and implementation flaws was the demonstration of subversion of the protection mechanism using malicious software (eg. trap doors and Trojan horses). [see the Rainbow Series’s Orange Book]
A series of enhancements were suggested that enabled Multics to serve in a relatively benign environment. These included addition of “mandatory access controls” and these enhancements were greatly enabled by the fact the Multics was designed from the start for security.
However, the bottom-line conclusion was that “restructuring is essential” around a verifiable “security kernel” before using Multics (or any other system) in an open environment (as in today’s Internet) with the existence of well-motivated professional attackers employing subversion.
The lessons learned from the vulnerability assessment are highly applicable today as governments and industry strive (unsuccessfully) to “secure” today’s weaker operating systems through add-ons, “hardening”, and intrusion detection schemes.
…No Buffer Overflows: One of the most common types of security penetrations today is the buffer overflow.6 However, when you look at the published history of Multics security problems [20, 28–30], you find essentially no buffer overflows. Multics generally did not suffer from buffer overflows, both because of the choice of implementation language and because of the use of several hardware features. These hardware and software features did not make buffer overflows impossible, but they did make such errors much less likely.
Programming in PL/I for Better Security
[length-specified strings rather than null-terminated; argument descriptor checking; higher-quality arrays & data structures; array bounds checking]
Hardware Features for Better Security
[hardware execute permission bits; segmented virtual memory; stacks which grow in positive direction rather than negative, reducing stack frame overwriting]
…There really seem to be only 4 possible conclusions from this: either (1) today’s systems are really much more secure than we claim; (2) today’s potential attackers are much less capable or motivated; (3) the information being processed is much less valuable; or (4) people are unwilling or unable to recognize the compelling need to employ much better technical solutions.
See Also: