Thirty Years Later: Lessons from the Multics Security Evaluation
Paul A. Karger

Roger R. Schell

IBM Corp., T. J. Watson Research Center
Yorktown Heights, NY 10598
karger@watson.ibm.com

Aesec Corporation
Pacific Grove, CA 93950
schellr@ieee.org

ABSTRACT
2
Almost thirty years ago a vulnerability assessment ofMultics identified significant vulnerabilities, despite thefact 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 (e.g.,
trap doors and Trojan horses). 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 averifiable “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 throughadd-ons, “hardening”, and intrusion detection schemes.

1

INTRODUCTION

In 1974, the US Air Force published [24] the results ofa vulnerability analysis of what was then the most secure
operating system available in the industry. That analysisof Multics examined not only the nature and significanceof the vulnerabilities identified but also the technology
and implementation prospects for effective solutions. The
results are still interesting today, because many of theconcepts of UNIX and other modern operating systems
came directly from Multics.
This paper revisits those results and relates them to thewidespread security problems that the computer industry
is suffering today. The unpleasant conclusion is that although few, if any, fundamentally new vulnerabilities areevident today, today’s products generally do not even
include many of the Multics security techniques, let alone
the enhancement identified as “essential.”

Multics Security Compared to Now

Multics offered considerably stronger security thanmost systems commercially available today. What factors
contributed to this?

2.1

Security as a Primary Original Goal

Multics had a primary goal of security from the very
beginning of its design [16, 18]. Multics was originallyconceived in 1965 as a computer utility – a large server
system on which many different users might process data.
This requirement was based on experience from developing and running the CTSS time sharing system at MIT.
The users might well have conflicting interests and therefore a need to be protected from each other – a need quite
like that faced today by a typical Application Service Provider (ASP) or Storage Service Provider (SSP). With thegrowth of individual workstations and personal computers, developers concluded (incorrectly) that security
was not as important on minicomputers or single-user
computers. As the Internet grew, it became clear thateven single-user computers needed security, but thoseintervening ill-founded decisions continue to haunt us
today. Today, the computer utility concept has returned[13], but today’s operating systems are not even up to thelevel of security that Multics offered in the early 1970s,
let alone the level needed for a modern computer utility.
There has been work on security for Computational Grids[12, 21], but this work has focused almost entirely on authentication and secure communication and not on the
security of the host systems that provide the utility.

2.2

Security as Standard Product Feature

One of the results of the US Air Force’s work on Multics security was a set of security enhancements [44] that
ultimately became the primary worked example whendefining the standard for Class B2 security in the Trusted
Computer System Evaluation Criteria (TCSEC) [2], better
known as the Orange Book. In the years that followed,
other similar enhancements [9, 11] were done for otheroperating systems, generally targeted for the much weaker
Class B1 level, but none of these security enhanced operating systems integrated as well with applications as theMultics enhancements had.
This was because unlike
ALL of the other security enhanced systems, the Multics

security enhancements were made part of the standard
product, shipped to ALL users, rather than only to thoseusers who specifically requested them. A significant reason why security enhancements to other operating systems were not integrated into the mainstream products
was that, unlike Multics, neither the operating systems nor
the applications generally were well structured for security, making security additions awkward.
While this difference might not seem significant initially, and indeed might even seem detrimental to the
manufacturer’s revenue stream (since security enhancements could command high prices), the reality was very
different. Because the Multics security enhancements,
including mandatory access controls, were shipped to
ALL customers, this meant that the designers of applications had to make sure that their applications worked
properly with those controls. By contrast, many application developers for other systems with optional security
enhancements don’t even know that the security enhancement options exist, let alone develop applications
that work with them.

2.3

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 muchless likely.
2.3.1 Programming in PL/I for Better Security
Multics was one of the first operating systems to be1
implemented in a higher level language. While the Multics developers considered the use of several languages,
including BCPL (an ancestor of C) and AED (Algol Extended for Design), they ultimately settled on PL/I [15].
Although PL/I had some influence on the developmentof C, the differences in the handling of varying length
data structures between the two languages can be seen asa major cause of buffer overflows. In C, the length of all
character strings is varying and can only be determined bysearching for a null byte. By contrast, PL/I character
strings may be either fixed length or varying length, but a
maximum length must always be specified, either at compile time or in an argument descriptor or in another variable using the REFER option. When PL/I strings are usedor copied, the maximum length specifications are honoredby the compiled code, resulting in automatic string truncation or padding, even when full string length checking is
not enabled. The net result is that a PL/I programmer
1 Burroughs’ use of ALGOL for the B5000 operating system was wellknown to the original Multics designers.

would have to work very hard to program a buffer overflow error, while a C programmer has to work very hard
to avoid programming a buffer overflow error.
Multics added one additional feature in its runtime
support that could detect mismatches between calling andcalled argument descriptors of separately compiled programs and raise an error.
PL/I also provides richer features for arrays and structures. While these differences are not as immediately
visible as the character string differences, an algorithm
coded in PL/I will have less need for pointers and pointerarithmetic than the same algorithm coded in C. Again,
the compiler will do automatic truncation or padding,even when full array bounds checking is not enabled.
While neither PL/I nor C are strongly typed languages
and security errors are possible in both languages, PL/I
programs tend to suffer significantly fewer security problems than the corresponding C programs.
2.3.2 Hardware Features for Better Security
Multics also avoided many of the current buffer overflow problems through the use of three hardware features.
First and most important, Multics used the hardware execute permission bits to ensure that data could not be directly executed. Since most buffer overflow attacks involve branching to data, denying execute permission todata is a very effective countermeasure. Unfortunately,
many contemporary operating systems have not used theexecute permission features of the x86 segmentation architecture until quite recently [17].
Second, Multics virtual addresses are segmented, andthe layout of the ITS pointers is such that an overflow off
the end of a segment does not carry into the segment
number portion. The net result is that addressing off theend of a segment will always result in a fault, rather thanreferencing into some other segment. By contrast, othermachines that have only paging (such as the VAX,SPARC, or MIPS processors) or that allow carries fromthe page offset into the segment number (such as the IBM
System/370) do not protect as well against overflows.
With only paging, a system has to use no-access guard
pages that can catch some, but not all references off theend of the data structure. In the case of the x86 processors, although the necessary segmentation features arepresent, they are almost never used, except for operating
systems specifically designed for security, such as GEMSOS [32].
Third, stacks on the Multics processors grew in thepositive direction, rather than the negative direction.
This meant that if you actually accomplished a buffer
overflow, you would be overwriting unused stack frames,
rather than your own return pointer, making exploitationmuch more difficult.

2.4

Minimizing Complexity

Multics achieved much of its security by structuring of
the system and by minimizing complexity. It is interest-ing to compare the size and complexity of Multics of thattime with current systems, such as the NSA’s Security
Enhanced Linux (SELinux). As documented in [41], thering 0 supervisor of Multics of 1973 occupied about 628K
bytes of executable code and read only data. This wasconsidered to be a very large system. By comparison, thesize of the SELinux module with the example policy [37]code and read only data has been estimated [22] to be
1767K bytes. This means that just the example security
policy of SELinux is more than 2.5 times bigger than theentire 1973 Multics kernel and that doesn’t count the sizeof the Linux kernel itself. These numbers are quite inexact, but they raise a warning. Given that complexity is thebiggest single enemy of security, it is important that the
SELinux designers examine whether or not there is acomplexity problem to be addressed.

Section 3.4.6 gave a brief hint of a trap door that was
installed into the 6180 development system at MIT in theroutine hcs_$set_ring_brackets_. We verified that thetrap door was distributed by Honeywell to the 6180 processor that was installed at the Air Force Data Services
Center (AFDSC) in the basement of the Pentagon in anarea that is now part of the Metro station. Despite the hint
in section 3.4.6, the trap door was not discovered untilroughly a year after the report was published. There wasan intensive security audit going on at the General Motors
Multics site, and the trap door, which was neutered toactually be benign, (it needed a one instruction change tobe actively malicious) gave an anomalous error return.
The finding of the trap door is described on the Multics
web site [45], although the installation of the trap door isincorrectly attributed to The MITRE Corporation.

3

3.2

Malicious Software

One of the major themes of the Multics Security
Evaluation was to demonstrate the feasibility of malicious
software attacks. Sadly, we were all too successful, andthe predictions of the report have been very prophetic.
At that time, we hypothesized that professional penetrators would find that distribution of malicious software
would prove to be the attack of choice. In the 1970s with
the Cold War raging, our assumption was that the mostimmediate professional penetrators would be foreign espionage agents and that the defense establishment would
be the target of choice, but we expected commercial penetrators to follow. Of course, malicious software (viruses,
worms, Trojan horses, etc.) is very common on the Internet today, targeting commercial and university interests aswell as the defense establishment. For example, The New
York Times has reported [36] on surreptitious add-ons tocertain peer-to-peer file sharing utilities that can also divert the revenue stream of commissions paid to affiliatesof electronic commerce web sites. While the legal statusof such add-ons is unclear, the reaction of affiliates who
have had their commissions diverted has been very negative. Anderson [8] shows some additional modern examples.

3.1

Installing Trap DoorsTo demonstrate our hypothesis, we not only looked for
exploitable flaws in Multics security, but we also attempted to plant trap doors into Multics to see if they
could be found during quality assurance and whether theywould be distributed to customer sites. Section 3.4.5.2 ofthe report described a trap door that was installed in the
645 processor, but was not distributed, as the 645 wasbeing phased out. This trap door did demonstrate a property expected of real-world trap doors – its activation was
triggered by a password or key that insured the vulnerability was not invoked by accident or discovered by quality
assurance or other testing.

Malicious Software Predictions

In addition to demonstrating the feasibility of installinga trap door into commercial software and having the
manufacturer then distribute it to every customer in theworld, the report also hypothesized a variety of other malicious software attacks that have unfortunately all cometrue. Section 3.4.5.1 proposed a variety of possible attack
points.
3.2.1 Malicious Developers
We suggested that malicious developers might create
malicious software. Since that time, we have seen many
products with either surreptitious backdoors that allow thedeveloper to gain access to customer machines or with socalled Easter eggs that are simply concealed pieces ofcode that do humorous things when activated. As expected of malicious trapdoors, activation of most Eastereggs is triggered by a unique key or password that is not
likely to be encountered in even extensive quality assurance testing. In most cases, the Easter eggs have NOT
been authorized by the development managers, and aregood examples of how developers can insert unauthorized
code. The primary difference between an Easter egg anda piece of malicious software is the developer’s intent.
Fortunately for most instances, the developers are notmalicious.
3.2.2 Trap Doors During Distribution
The report predicted trap doors inserted into the distribution chain for software. Today, we frequently see bogus e-mail or downloads claiming to contain important
updates to widely used software that in fact contain Trojan horses. One very recent incident of this kind is reported in [19].
3.2.3 Boot-Sector Viruses
The report predicted trap doors during installation andbooting. Today, we have boot sector viruses that arequite common in the wild.

3.2.4 Compiler Trap Doors
The trap doors described in the report were patches tothe binary object files of the system. The report suggested a countermeasure to such object code trap doors byhaving customers recompile the system from source, although the report also notes that this could play directly
into the hands of the penetrator who has made changes inthe source code. In fact, the AFDSC Multics contract
specifically required that Honeywell deliver source code
to the Pentagon to permit such recompilations. However,
the report pointed out the possibility that a trap door in the
PL/I compiler could install trap doors into the Multics
operating system when modules were compiled and could
maintain its own existence by recognizing when the PL/I
compiler was compiling itself. This recognition was thebasis several years later for the TCSEC Class A1 requirement for generation of new versions from source
using a compiler maintained under strict configuration
control. A recent story on CNET news [14] reports that
the Chinese government has similar concerns aboutplanted trap doors.
This suggestion proved an inspiration to Ken Thompson who actually implemented the self-inserting compiler
trap door into an early version of UNIX. Thompson described his trap door in his 1984 Turing Award paper[40], and attributed the idea to an “unknown Air Forcedocument,” and he asked for a better citation. The document in question is in fact the Multics Security Evaluation
report, and we gave a new copy of the report to Thompson after his paper was published. Thompson has corrected his citation in a reprint of the paper [39].

3.3

Auditing and Intrusion Detection

Multics had some limited auditing capabilities (basically recording date time modified (DTM) on files) at thetime of the original vulnerability analysis, although agreat deal more auditing was added as part of the Multics
Security Enhancements project [44].
Section 3.4.4
showed how a professional attacker could bypass the auditing capabilities while installing malicious software.
This has major implications for today, because intrusion detection has become a major area of security product development. Unfortunately, many of the intrusion
detection systems (IDSs) that have been developed do notdeal well with the possibility of a professional attacker
going in and erasing the evidence before it can be reported to an administrator to take action. Most IDSs relyon pattern recognition techniques to identify behaviors
that are indicative of an attack. However, a professional
penetrator would do as we did – debug the penetration
programs on a duplicate machine, the Rome Air Defense
Center Multics system in our case, before attacking thedesired target, the MIT site in our case. This would give
the IDS only a single isolated anomaly to detect, and the
IDS would have to respond before the professional attacker could erase the evidence as we did with the Multics
DTM data.

Most evaluations of IDS systems have focused on how
well the IDS responds to a series of pre-recorded traces.
A more relevant evaluation of an IDS system would be tosee how it responds to a well-prepared and well-funded
professional (but ethical) attacker who is prepared to erase
the auditing data and to install trap doors immediately forlater exploitation, or subvert the operating system on
which the IDS is running to selectively bypass the IDS all
together. This type of selectively triggered attack of alimited subsystem (i.e., the IDS) through a subverted hostoperating system is illustrated by the “key string trigger
trap door” in section 3.4.5.1 of the report.

4

What Happened Next?

This section discusses the immediate outcomes fromthe Vulnerability Analysis.

4.1

Multics Security Enhancements

The primary outcome of the vulnerability analysis, andindeed the reason it was done at all was the Multics security enhancements effort [44]. The Air Force had initiallyapproached Honeywell with a proposal for an R&D effort
to improve Multics security for the Air Force Data Services Center, but Honeywell initially declined on the basisthat Multics was already sufficiently secure. The vulnerability analysis was conducted to provide evidence of theneed for significant enhancements. This security enhanced version of Multics ultimately achieved a Class B2
evaluation from the National Computer Security Center in1985 [3].

4.2

Publicity

The results of the vulnerability received a certain levelof press publicity. Fortune magazine published [7] aninterview with Steve Lipner of the MITRE Corporationthat was a bit sensationalized. It focused on the illegal
operator’s console message described in section 3.3.4.3.
That message quoted from a Honeywell press release thatappeared in an internal Honeywell newsletter and a Phoe2
nix, AZ newspaper article that incorrectly stated that the
Air Force had found some security problems in Multics,
but they were all fixed and that the Air Force now “certified” Multics security. Not only was the Honeywell press
release inaccurate, but it had not been cleared for public
release, as required in the Multics security enhancements
contract. While the Fortune article was a bit sensational,
the story was then retold in a text book [26] in a version
that was barely recognizable to us.
A much better description of the work was done by
Whiteside[43], based on his earlier articles for The New
Yorker. Whiteside interviewed both Schell and Lipnerand did a much more accurate account of the effort.

2 The authors have been unable to find copies of these articles andwould appreciate any information on how to locate them.

4.3

Multics Kernel Design Project

As the report suggested in section 4.2.2, a project wasstarted to build a security kernel version of Multics, one
intended to ultimately meet what was later defined as therequirements of a Class A1 evaluation of the Orange
Book [2]. This effort was conducted jointly by Honeywell, MIT, the MITRE Corporation, and the Air Forcewith results published in: [10, 33-35, 38].

4.4

Direction to Stop Work

In August 1976, Air Force Systems Command directed
termination of the Air Force’s computer security work,
including the Multics Kernel Design Project, despite thefact that the work was quite successful up to that point,
had widespread support from user agencies in the Army,
the Navy, and the Air Force, and had been by DoD standards, quite inexpensive. The adverse impact of that termination on the DoD is described in [31]. Another viewof those events can be seen in [23, pp. II-74 – II-75] andin the GAO report on the termination [4].

5Dispelling Mythology

The Multics vulnerability analysis got enough publicity that a certain amount of mythology developed about
what happened. We hope this section can dispel at least
some of that mythology.
One story that circulated was that the penetrations
were only possible, because the authors had special privileged access to Multics. While both authors had been
members of the MIT Multics development team (Roger
Schell as a Ph.D. student and Paul Karger as an undergraduate), both had left the Multics team months before
the vulnerability analysis was even considered. No privileged accounts on either of those systems were used in theanalysis. (Privileged accounts were used on RADCMultics and at the Air Force Data Services Center, but
those were only to show that a penetrator could take advantage of a duplicate system to debug penetrations aheadof time and to verify the distribution of the trap door.)
The Air Force purchased computer time on the MITMultics system and on Honeywell’s Multics system in
Phoenix, AZ, but both systems routinely sold computer
time. Multics source code was readable by any user on
the MIT site, much as source code for open source systems is generally available today.
The entire vulnerability analysis was carried out with aground rule of not causing any real harm to any of thesystems under attack. All the documentation and listingsof exploit programs was kept in a safe approved for storing TOP SECRET information (although that particularsafe actually had no classified material in it). Decrypted
password files were also stored in the safe, to ensure thatno user accounts would be compromised. Exploit programs were protected with very restrictive access control
lists and kept encrypted at all times, except when actuallyin use. The applicable contracts specified that the pur-chased computer time at MIT and Phoenix would be used
for security testing and evaluation purposes, so there wasno question of the legality of the analysis. Finally, publication of [24] was delayed until after all of the penetrations described were repaired.
For several years after the completion of the vulnerability analysis, the authors were periodically contacted
when unexplained system crashes occurred on the MIT
site, just in case they had been caused by a remaining hidden trap door. However, as part of the basic policy of theanalysis to cause no real harm, no trap doors were left
behind after the conclusion of the vulnerability analysis.

6

Security has gotten worse, not better

Today, government and commercial interest in achieving processing and connectivity encompassing disparate
security interests is driving efforts to provide security
enhancements to contemporary operating systems [27].
These efforts include the addition of mandatory access
controls and “hardening” (i.e., the removal of unnecessary
services.) Such enhancements result in systems less secure than Multics, and Multics, with its security enhancements, was only deemed suitable for processing in a
relatively benign “closed” environment [5]. It was concluded that operation of Multics in an “open” environment would require restructuring around a verifiable security kernel to address the threat of professional attacks
using malicious software (e.g., trap doors).

6.1

Weak Solutions in Open Environments

Given the understanding of system vulnerabilities thatexisted nearly thirty years ago, today’s “security enhanced” or “trusted” systems would not be considered
suitable for processing even in the benign closed environment. Also, considering the extent of network interconnectivity and the amount of commercial off-the-shelf(COTS) and other software without pedigree (e.g., libraries mined from the Web), today’s military and commercial environments would be considered very much“open”. To make matters worse, everyone is now expected to be a system administrator of their own desktop
system, but without any training!
Furthermore, quality assurance testing and subjecting
systems to authorized (ethical) hackers are among themost common approaches for concluding that the securityof such systems is adequate. There have even been apparently serious proposals [1] for something as importantas voting to use student hackers “to test computerized
voting systems”. Yet it is evident on the face of it thatsuch approaches are utterly useless for detecting the vulnerability most attractive to a professional – malicious
software triggered by a unique key or password unknown3
to those making this assessment.
3 Note that this does not mean that penetration testing or ethical hacking
has no use. One of the authors currently works in IBM’s Global Security Analysis Laboratory, an ethical hacking organization. Penetration

Thus, systems that are weaker than Multics are considered for use in environments in excess of what even Multics could deliver without restructuring around a security
kernel. There really seem to be only four possible conclusions from this: either (1) today’s systems are reallymuch 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.

commentary. Tom was the system administrator and adesigner of Multics, so we also thank him (nearly 30 years
later) for understanding that our work was to make Multics more secure, even if its presentation was considered
overly dramatic at times.

6.2

2. Department of Defense Trusted Computer System Evaluation
Criteria, DOD 5200.28-STD, December 1985: Washington, DC.
URL: http://csrc.nist.gov/publications/history/dod85.pdf

Technical Solutions

Though Multics was never restructured around a security kernel as recommended, the technical ability to structure a full featured commercial operating system around akernel designed to meet Class A1 while maintaining good
operating system and application compatibility was demonstrated for the VAX [25]. Successful fielding on the
open Internet of a highly secure system using the popular
x86 processor with the commercial NSA-certified Class
A1 GEMSOS [32] security kernel for VPN security management has also been demonstrated [42].
In the nearly thirty years since the report, it has been
demonstrated that the technology direction that was
speculative at the time can actually be implemented andprovides an effective solution to the problem of malicious
software employed by well-motivated professionals. Unfortunately, the mainstream products of major vendors
largely ignore these demonstrated technologies. In theirdefense most of the vendors would claim that the marketplace is not prepared to pay for a high assurance of security. And customers have said they have never been offered mainstream commercial products that give themsuch a choice, so they are left with several ineffective
solutions collected under marketing titles like “defense indepth”.
In our opinion this is an unstable state of affairs. It is
unthinkable that another thirty years will go by without
one of two occurrences: either there will be horrific cyberdisasters that will deprive society of much of the value
computers can provide, or the available technology will
be delivered, and hopefully enhanced, in products thatprovide effective security. We hope it will be the latter.

7

Acknowledgments

We must thank Iris Partlow of the IBM Business Support Center for retyping the 1974 report. Very helpfulcomments came from Mike Thompson of Aesec Corporation, Jeremy Epstein of webMethods, Wietse Venema
and David Safford of IBM Research, Steve Sutton of PatientKeeper, and Tom Van Vleck of NAI Labs. Tom also
runs the Multics web site (http://www.multicians.org),
where we found some of the information needed for thistesting can identify some vulnerabilities for repair. However, the failureof any particular penetration team to find vulnerabilities does not imply
their absence. It only indicates that the team failed to find any.

REFERENCES
1. Broward Officials Want Students to Try Hacking Mock Election, in Assoc. Press 16 August 2001: Ft. Lauderdale, FL. URL:
http://www.wtsp.com/news/2001_08/16_mock_election.htm

3. Final Evaluation Report of Multics, MR11.0, CSC-EPL85/003 (releasable only to US Government and their contractors), 1 September 1985, National Computer Security Center: Ft.
George G. Meade, MD. URL:
http://www.radium.ncsc.mil/tpep/library/fers/tcsec_fers.html
4. Multilevel Computer Security Requirements of the World
Wide Military Command and Control System (WWMCCS),
LCD-78-106, 5 April 1978, General Accounting Office: Washington, DC. URL:
http://www.gao.gov/docdblite/summary.php?&rptno=LCD-78106
5. Technical Rationale Behind CSC-STD-003-85: Computer
Security Requirements -- Guidance for Applying the Departmentof Defense Trusted Computer System Evaluation Criteria in
Specific Environments, CSC-STD-004-85, 25 June 1985, DoD
Computer Security Center: Ft. George G. Meade, MD.
6. Aleph One, Smashing the Stack for Fun and Profit. Phrack,
8 November 1996. 7(49). URL:
http://www.phrack.org/show.php?p=49&a=14
7. Alexander, T., Waiting for the Great Computer Rip-off. Fortune, 1974. XC(1): p. 142-150.
8. Anderson, E.A., III, A Demonstration of the Subversion
Threat: Facing a Critical Responsibility in the Defense of Cyberspace, M.S. in Computer Science 2002, Naval Postgraduate
School: Monterrey, CA. URL:
http://theses.nps.navy.mil/Thesis_02Mar_Anderson_Emory.pdf
9. Berger, J.L., J. Picciotto, et al., Compartmented Mode Workstation: Prototype Highlights. IEEE Transactions on Software
Engineering, June 1990. 16(6): p. 608-618.
10. Biba, K.J., S.R. Ames, et al., A Preliminary Specification ofa Multics Security Kernel, WP-20119, April 1975, The MITRE
Corporation: Bedford, MA.
11. Blotcky, S., K. Lynch, et al. SE/VMS: Implementing Mandatory Security in VAX/VMS. in Proceedings of the 9th National Computer Security Conference. 15-18 September 1986,
Gaithersburg, MD National Bureau of Standards. p. 47-54.
12. Butler, R., V. Welch, et al., A National-Scale Authentication
Infrastructure. Computer, December 2000. 33(12): p. 60-66.

13. Carr, D.F., The Hot Hand in the ASP Game. Internet
World, 15 January 2000. 6(2): p. 53. URL:
http://www.internetworld.com/magazine.php?inc=011500/1.15c
over_story.html
14. Cooper, C., Who says paranoia doesn't pay off? CNET
News.com, 20 September 2002. URL:
http://news.com.com/2010-1071-958721.html
15. Corbató, F.J., PL/I As a Tool for System Programming.
Datamation, May 1969. 15(5): p. 68-76. URL:
http://home.nycap.rr.com/pflass/plisprg.htm
16. Corbató, F.J. and V.A. Vyssotsky. Introduction and Overview of the Multics System. in Fall Joint Computer Conference. 1965, Washington, DC Vol. AFIPS Conference Proceedings Vol. 27. Spartan Books. p. 185-196. URL:
http://www.multicians.org/fjcc1.html
17. Cowan, C., P. Wagle, et al. Buffer Overflows: Attacks andDefenses for the Vulnerability of the Decade. in DARPA Information Survivability Conference and Expo (DISCEX).
25-27 January 2000, Hilton Head Island, SC Vol. 2. p. 119-129.
URL: http://www.immunix.org/StackGuard/discex00.pdf
18. David, E.E., Jr. and R.M. Fano. Some Thoughts About theSocial Implications of Accessible Computing. in Fall Joint
Computer Conference. 1965, Washington, DC Vol. AFIPS
Conference Proceedings Vol. 27. Spartan Books. p. 243-247.
URL: http://www.multicians.org/fjcc6.html
19. Dougherty, C., Trojan Horse OpenSSH Distribution,
CERT® Advisory CA-2002-24, 2 August 2002, CERT Coordination Center, Carnegie Mellon University: Pittsburgh, PA.
URL: http://www.cert.org/advisories/CA-2002-24.html
20. Forsdick, H.C. and D.P. Reed, Patterns of Security Violations: Multiple References to Arguments, in Ancillary Reports:
Kernel Design Project, D.D. Clark, Editor, June 1977,
MIT/LCS/TM-87, Laboratory for Computer Science, Massachusetts Institute of Technology: Cambridge, MA. p. 34-49.

26. Logsdon, T., Computers & Social Controversy, 1980, Computer Science Press: Potomoc, MD. p. 170-175, 185.
27. Loscocco, P. and S. Smalley. Integrating Flexible Support
for Security Policies into the Linux Operating System. in Proceedings of the FREENIX Track: 2001 USENIX Annual
Technical Conference (FREENIX '01). 2001, Boston, MA.
URL: http://www.nsa.gov/selinux/doc/freenix01.pdf
28. Saltzer, J.H., Repaired Security Bugs in Multics, in Ancillary Reports: Kernel Design Project, D.D. Clark, Editor, June
1977, MIT/LCS/TM-87, Laboratory for Computer Science,
Massachusetts Institute of Technology: Cambridge, MA. p. 1-4.
29. Saltzer, J.H. and D. Hunt, Some Recently Repaired Security
Holes of Multics, in Ancillary Reports: Kernel Design Project,
D.D. Clark, Editor, June 1977, MIT/LCS/TM-87, Laboratory for
Computer Science, Massachusetts Institute of Technology:
Cambridge, MA. p. 28-33.
30. Saltzer, J.H., P. Jansen, et al., Some Multics Security Holes
Which Were Closed by 6180 Hardware, in Ancillary Reports:
Kernel Design Project, D.D. Clark, Editor, June 1977,
MIT/LCS/TM-87, Laboratory for Computer Science, Massachusetts Institute of Technology: Cambridge, MA. p. 22-27.
31. Schell, R.R. Computer security: the Achilles' heel of theelectronic Air Force? in Air University Review. JanuaryFebruary 1979, Vol. 30. p. 16-33. URL:
http://www.airpower.maxwell.af.mil/airchronicles/aureview/197
9/jan-feb/schell.html
32. Schell, R.R., T.F. Tao, et al. Designing the GEMSOS Security Kernel for Security and Performance. in Proceedings of the
8th National Computer Security Conference. 30 September 3 October 1985, Gaithersburg, MD DoD Computer Security
Center and National Bureau of Standards. p. 108-119.
33. Schiller, W.L., P.T. Withington, et al., Top Level Specification of a Multics Security Kernel, WP-20810, 9 July 1976, The
MITRE Corporation: Bedford, MA.

21. Foster, I., C. Kesselman, et al. A Security Architecture for
Computational Grids. in Proceedings of the 5th ACM Conference on Computer and Communications Security. 2-5 November 1998, San Francisco, CA p. 83-92.

34. Schroeder, M.D., Engineering a Security Kernel for Multics. Proceedings of the Fifth Symposium on Operating Systems Principles, Operating Systems Review, November 1975.
9(5): p. 25-32.

22. Jaeger, T., Personal Communication, 30 July 2002, IBM
Corp., T. J. Watson Research Center: Hawthorne, NY.

35. Schroeder, M.D., D.D. Clark, et al., The Multics Kernel
Design Project. Proceedings of the Seventh ACM Symposium
on Operating Systems Principles, Operating Systems Review, November 1977. 11(5): p. 43-56.

23. Jelen, G.F., Information Security: An Elusive Goal, P-85-8,
June 1985, Program on Information Resources Policy, Harvard
University: Cambridge, MA. URL:
http://www.pirp.harvard.edu/publications/pdf-blurb.asp?id=238
24. Karger, P.A. and R.R. Schell, Multics Security Evaluation:
Vulnerability Analysis, ESD-TR-74-193, Vol. II, June 1974, HQElectronic Systems Division: Hanscom AFB, MA. URL:
http://csrc.nist.gov/publications/history/karg74.pdf
25. Karger, P.A., M.E. Zurko, et al., A Retrospective on the
VAX VMM Security Kernel. IEEE Transactions on Software
Engineering, November 1991. 17(11): p. 1147-1165.

36. Schwartz, J. and B. Tedeschi, New Software Quietly Diverts
Sales Commissions. The New York Times, 27 September 2002:
p. C1-C4. URL:
http://www.nytimes.com/2002/09/27/technology/27FREE.html
37. Smalley, S., Configuring the SELinux Policy, NAI Labs
Report #02-007, June 2002, NAI Labs: Glenwood, MD. URL:
http://www.nsa.gov/selinux/policy2-abs.html
38. Stern, J., Multics Security Kernel Top Level Specification,
ESD-TR-76-368, November 1976, Honeywell Information Sys-

tems, Inc., McLean, VA, HQ Electronic Systems Division:
Hanscom AFB, MA.
39. Thompson, K., On Trusting Trust. Unix Review, November
1989. 7(11): p. 70-74.
40. Thompson, K., Reflections on Trusting Trust. Communications of the ACM, August 1984. 27(8): p. 761-763.
41. Voydock, V.L., A Census of Ring 0, in Ancillary Reports:
Kernel Design Project, D.D. Clark, Editor, June 1977,
MIT/LCS/TM-87, Laboratory for Computer Science, Massachusetts Institute of Technology: Cambridge, MA. p. 5-27.
42. Weissman, C. BLACKER: Security for the DDN. Examplesof A1 Security Engineering Trades. in 1992 IEEE Computer
Society Symposium on Research in Security and Privacy. 4-6
May 1992, Oakland, CA p. 286-292.
43. Whiteside, T., Trapdoors and Trojan Horses, in Computer
Capers. 1978, Thomas Y. Crowell Co.: New York. p. 115-126.
44. Whitmore, J., A. Bensoussan, et al., Design for Multics
Security Enhancements, ESD-TR-74-176, December 1973,
Honeywell Information Systems, Inc., HQ Electronic Systems
Division: Hanscom AFB, MA. URL:
http://csrc.nist.gov/publications/history/whit74.pdf
45. Zemmin, F., B. Henk, et al., Multics Site History: GM, T.H.
Van Vleck, Editor, 20 October 1998. URL:
http://www.multicians.org/site-gm.html