Thirty Years Later: Lessons from the Multics Security Evaluation Paul A. Karger Roger R. Schell IBM Corp., T. J. Watson Research Center Aesec Corporation Yorktown Heights, NY 10598 Pacific Grove, CA 93950 [email protected] [email protected] ABSTRACT Almost thirty years ago a vulnerability assessment of Multics identified significant vulnerabilities, despite the fact that Multics was more secure than other contempo-rary (and current) computer systems. Considerably more important than any of the individual design and imple-mentation 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 rela-tively 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 con-clusion 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. 1 INTRODUCTION In 1974, the US Air Force published [24] the results of a vulnerability analysis of what was then the most secure operating system available in the industry. That analysis of Multics examined not only the nature and significance of the vulnerabilities identified but also the technology and implementation prospects for effective solutions. The results are still interesting today, because many of the concepts of UNIX and other modern operating systems came directly from Multics. This paper revisits those results and relates them to the widespread security problems that the computer industry is suffering today. The unpleasant conclusion is that al-though few, if any, fundamentally new vulnerabilities are evident today, today’s products generally do not even include many of the Multics security techniques, let alone the enhancement identified as “essential.” 2 Multics Security Compared to Now Multics offered considerably stronger security than most 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 originally conceived 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 develop-ing and running the CTSS time sharing system at MIT. The users might well have conflicting interests and there-fore a need to be protected from each other – a need quite like that faced today by a typical Application Service Pro-vider (ASP) or Storage Service Provider (SSP). With the growth of individual workstations and personal com-puters, developers concluded (incorrectly) that security was not as important on minicomputers or single-user computers. As the Internet grew, it became clear that even single-user computers needed security, but those intervening 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 the level 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 au-thentication 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 Mul-tics security was a set of security enhancements [44] that ultimately became the primary worked example when defining 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 other operating systems, generally targeted for the much weaker Class B1 level, but none of these security enhanced oper-ating systems integrated as well with applications as the Multics enhancements had. This was because unlike ALL of the other security enhanced systems, the Multicssecurity enhancements were made part of the standard product, shipped to ALL users, rather than only to those users who specifically requested them. A significant rea-son why security enhancements to other operating sys-tems were not integrated into the mainstream products was that, unlike Multics, neither the operating systems nor the applications generally were well structured for secu-rity, making security additions awkward. While this difference might not seem significant ini-tially, and indeed might even seem detrimental to the manufacturer’s revenue stream (since security enhance-ments 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 applica-tions had to make sure that their applications worked properly with those controls. By contrast, many applica-tion developers for other systems with optional security enhancements don’t even know that the security en-hancement 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