5.6 Implementation Examples

 <  Free Open Study  >  

This chapter has focused on designing the security aspects of operating systems, which in turn can contribute to the overall security of a computing system. Fortunately, not every application requires A1- or F “A1/E6-quality security; few operating systems have the features needed to make them A1 or have been built with the care and discipline necessary to be judged E6.

In this section, we examine several commonly used operating systems, looking at features such as access control, security kernel, and design. Two examples are drawn from the general commercial world, and two more from the restricted world of TCSEC-inspired systems. We cover only features relevant to security, and then only some of those features.

General-Purpose Operating Systems

Several general-purpose operating systems are in wide use, affecting not only the development we do but also the applications we run as professionals and consumers. Unix is one such system, and we explore some of its design and development characteristics that have had an impact on its security. We also look at IBM's PR/SM, in widespread use on mainframe computers and whose origin and development have influenced its security.

Unix

The Unix operating system was never intended to have a high degree of security. It was designed in 1969 by two programmers, Ken Thompson and Dennis Ritchie, primarily for their own use in developing, testing, and maintaining programs. The system was intended for use in "nonhostile" environments, such as research laboratories and universities, where the advantages of easy object sharing far outweighed the possibility of unfriendly access.

As a result, sharing of files, data, devices, and storage volumes is relatively simple, unencumbered by a strong protection mechanism. The Unix system administrator is as sumed to be a programmer too, who administers only part of the time and who does not, cannot, or should not perform many security functions.

Unix grew essentially without plan. When Bell Laboratories decided to withdraw from the Multics project, the early Unix designers, Thompson, Ritchie, Doug McIlroy, and J. F. Ossanna, were programmers there. Multics had provided them with interactive use of a computing utility, so they searched for another available machine on which to write their system. The philosophy and structure of Unix derived largely from Thompson, who designed the initial version and was heavily involved in the system's development for over a decade .

Thompson's goal was to provide a simple toolbox in which a user could store and access a variety of tools, combining them as needed for individual uses. Generality and compactness were prominent in the design of the elementary Unix functions, still a hallmark of the operating system today. Unix was intended to be extensible, even though this freedom brought security problems. If each user could add to the functionality of Unix, so could a malicious user . Simplicity and economy of design are virtues for the users, but they are a nightmare to the designer of a secure system. Thus, security side effects accompany many of the Unix commands.

There is one identified user, called the superuser, who can perform essentially any operation in the system. Because the superuser is all-powerful, most system attacks are aimed at obtaining superuser rights. Having obtained this right once, even for only a few seconds, a penetrator can establish a trapdoor that permits superuser access at any time in the future.

A user sharing access to a system program can obtain high security rights if the system program runs in setuid mode. As we noted earlier in this chapter, when a user executes such a program, the file access rights during program execution are the rights of the program's owner, not the program's user. The intended purpose of this feature is to allow a user to use a utility program, such as mail , and through the program access files at the level of mail . However, most sensitive utility programs are "owned" by the superuser, so that a security flaw exploited in one utility program gives very wide access.

From the point of view of the Unix operating system, all objects ”directories, I/O devices, even parts of memory ”are files, and they are accessed with the same structure. Again, this simplicity is good for the user, but it makes security difficult. File access permission is checked only once, when the file is opened. By changing the characteristics of the file or device after it has been opened, a user can obtain unchecked access permission.

Unix is distributed in modular form: An individual installation decides which features or modules it wants to use. Administrators can acquire modules from a wide range of external providers or even write their own and link them into the Unix operating system. A user can also build an individual environment of commands and functions. Of course, for Unix to support additions and replacements , all Unix interfaces must be clearly and completely documented, which they usually are. This ability to change is an advantage to attackers , who can replace practically any functions, including login, password management, object-level access control, and auditing, often without the knowledge of administrators or users.

Unix provides reasonable security for the environment for which it was designed: essentially a friendly environment. However, the inherent lack of security in the basic Unix system is evident from the fact that Unix-based secure operating systems have actually been implemented by substantial rewrites of the Unix kernel, to provide a system that has the outward functionality of Unix with a different internal structure. Sibert et al. [SIB87] describe the difficulties that would occur if Unix were to be evaluated for B2 certification.

PR/SM

Strictly speaking, the IBM Processor Resources/System Manager (PR/SM) is not really an operating system. Rather, it is a resource manager that provides strong separation and strictly controlled sharing of virtual machines. PR/SM does not support ordinary user tasks ; instead, its "users" are other operating systems. PR/SM derives from a long line of IBM mainframe virtual machine operating systems, including VM/370 and MVS. It consists of a logical partition manager (LPAR) that maps physical devices and hardware interactions to signals passed between LPAR and each subject operating system.

PR/SM implements a very simple security policy: strict separation. All resources are partitioned into separate domains so that resources and processes running in one domain are unaware of and perceive no effect from resources and processes in other domains. PR/SM manages all hardware resources, which are shared only serially . In other words, before each resource (such as memory or processor registers) is to be reallocated to another operating system, the resource is completely purged of data. Other resources, such as direct access storage devices, are allocated to just one domain.

PR/SM was intended to support two or more different operating systems on a single computing system. Such a system might be desirable during a gradual changeover from one operating system to another so that both systems could be available at the same time. Or we may want to be able to change and test one operating system in an environment in which a system error in one (virtual) machine would not affect other users.

Virtualization was originally designed to provide flexibility in addressing and memory management; security was achieved as a bonus. PR/SM turned out to have a security advantage as well. Because LPAR performs all actual interaction with hardware, it acts as a second security layer between the operating system and the hardware.

To see how, suppose a user identifies and exploits a vulnerability in the operating system (that is, in the operating system running in the user's virtual machine, such as MVS/ESA). Under PR/SM, the user might extend outside the user domain and reach the operating system domain (where MVS/ESA is run). Even so, the user still does not have access to the actual machine hardware nor to users or domains running on other operating systems on other virtual machines. To penetrate another user or operating system, the user would have to find and exploit yet another vulnerability, this one in the security mechanism of PR/SM itself.

The separation advantages reach beyond security concerns. Strictly separate domains permit an installation to run a testing environment without risking interference with a domain supporting commercial needs. Separate domains can also serve as redundant backup capabilities, ready to take over instantly in the event of a hardware or software failure. Finally, separate domains can run different operating systems for separate communities of users.

PR/SM security capabilities include extensive hardware and software support for domain separation, strong role-based security management for such actions as configuring the partitioning of resources to domains, audit of actions of security administrators, and a secure communications path to PR/SM from security administrators and from the domains.

Operating Systems Designed for Security

Commercial operating systems such as Unix and PR/SM meet well-defined security needs. For example, Unix supposes an environment of trustworthy collaborators, and PR/SM anticipates situations requiring protection against inadvertent or malicious attempts by a process in one domain to interfere with one in another domain. Unix's degree of security is moderate, but PR/SM's is high, implemented largely by hardware to avoid a major performance penalty. Each approach is appropriate; the security requirements for these systems are commensurate with the degree of threat expected.

We must also consider operating systems designed for environments having far greater security needs. In the 1970s and 1980s, much effort was invested in the research, design and implementation of trusted operating systems. Projects such as KVM [GOL77, GOL84], KSOS [MCC79], Scomp [FRA83], Multics [SAL74], and TMach [BRA89, TIS97] were noble research efforts that never had enough commercial impact to keep their products alive . In these cases, the design addressed security as the foremost requirement, with such factors as usability and efficiency having lower importance. Regardless of past disappointments, such systems have great potential for government security applications, diplomatic communication, or projects in which the value of the system assets is high. The VAX security kernel was one such system, intended to meet both high security and ordinary commercial requirements.

VAX Security Kernel

The VAX Security Kernel, a project of Digital Equipment Corporation, targeted the A1 level of the TCSEC. It would have led to a very high assurance (A1) security kernel supporting the widely used commercial operating systems VMS and Ultrix. Standard VMS utilities and other software would have run on the security kernel, so it would have had a large number of widely used, well-supported applications. This kernel would have been the bridge between high assurance and mainstream commercial operating systems.

The security kernel faithfully emulated the underlying VAX hardware, including exporting all privilege states (virtualized versions), virtualized I/O (through monitoring of specific memory locations that reflect I/O data and status registers), and virtualized memory. The security kernel concurrently enforced Bell “La Padula mandatory confidentiality and Biba mandatory integrity.

The design of the security kernel was carefully constructed in 16 layers, each of which exported a capability to the layers above but depended on only layers below. This layered structure simplified debugging and imposed an order on the system's data and control flows. The layers protected themselves from above.

The A1 requirements dictated a development philosophy and methodology, starting with a formal model of security policy, a formal presentation of the highest-level design, and an argument that the formal design carried through to the implementation. The VAX security kernel was developed with rigid configuration control. In fact, it was built twice, once as a research and learning vehicle and once for real. Performance was significantly better in the second version.

The project began as a proposal for a research prototype in 1981, which was implemented between 1982 and 1984. This first version was redone as a production quality system by 1988. Tuning, additional development, and final documentation and preparation for the evaluation took place between 1988 and 1990. But in 1990 the project was terminated . Two reasons have been cited for the termination: corporate unwillingness to support multiple versions of the VAX family of operating systems (one for the security kernel and the other for general ”not A1 ”distribution) and export control restrictions.

Nevertheless, the VAX virtual machine monitor project remains an outstanding example of high-quality development of trusted systems. Excellent descriptions of this project, especially of the security design issues, can be found in [KAR90, KAR91a]. Among other things, the project demonstrates the importance of building in security from the beginning of the development process. By contrast, most of the many examples of inserting security after the fact end in disappointment and unsatisfactory compromise. Sidebar 5-6 tells one of these tales.

Sidebar 5-6 Security As an Add-On

In the 1980s, the U.S. State Department handled its diplomatic office functions with a network of Wang computers. Each American embassy had at least one Wang system, with specialized word processing software to create documents, modify them, store and retrieve them, and send them from one location to another. Supplementing Wang's office automation software was the State Department's own Foreign Affairs Information System (FAIS).

In the mid-1980s, the State Department commissioned a private contractor to add security to FAIS. Diplomatic and other correspondence was to be protected by a secure "envelope" surrounding sensitive materials. The added protection was intended to prevent unauthorized parties from "opening" an envelope and reading the contents.

To design and implement the security features, the contractor had to supplement features offered by Wang's operating system and utilities. The security design depended on the current Wang VS operating system design, including the use of unused words in operating system files. As designed and implemented, the new security features worked properly and met the State Department requirements. But the system was bound for failure because the evolutionary goals of VS were different from those of the State Department. That is, Wang could not guarantee that future modifications to VS would preserve the functions and structure required by the contractor's security software. Eventually, there were fatal clashes of intent and practice.

 <  Free Open Study  >  


Security in Computing
Security in Computing, 4th Edition
ISBN: 0132390779
EAN: 2147483647
Year: 2002
Pages: 129

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net