Case (c): New Operating System

The third case arises when you are designing your own system from scratch, and thus have the rare freedom (within reason) to define your own operating system interface. This case of course assumes that you are designing a complete operating system and not just a kernel. In case (c) you are allowed to define an operating system interface that is compatible with the security policy enforced by the kernel. The interface might closely match the functions provided by the kernel, either on a one-for-one basis or through simple mappings of operating system functions to kernel functions. With the flexibility afforded by the freedom to choose an interface, you can probably design both a kernel of minimal size and an operating system that performs well. With appropriate hardware support (see chapter 8), your fully functional secure operating system need perform no worse than any insecure operating system that has similar functions.

The SCOMP is an example of a kernelized system with a specialized operating system. On top

of the kernel is a simple operating system that provides more application-friendly features than the bare kernel does.

The structure of the system will resemble that in figure 10-4, with a portion of the operating system code running in each process under control of the kernel. But because there is no compatibility constraint on the type of sharing that the operating system must implement, you can design both the file system’s and the operating system’s internal databases to use kernel primitives to share information in accordance with the security policy. This flexibility minimizes the need to implement special-purpose functions in the kernel.

If you have a multilevel security policy, for example, a process running at SYSTEM LOW

(see section 9.5.3) outside the kernel can write information readable by all other processes. Such a process can manage a large number of administrative functions affecting system databases that are read (but not written) by other processes. These include the user registration file, configuration information, sysgen parameters, and start-up procedures.

A SYSTEM HIGH process outside the kernel can handle functions that must be able to read system-wide information written by all processes. Such a process can read (but not write) any file in the system without special privileges. Examples of applications of this type are processes that handle audit or accounting logs or that monitor system usage.

You cannot go too far with this notion of untrusted processes for system functions. The system backup process, for example, only requires read access to files and might therefore seem to be a good candidate for a SYSTEM HIGH untrusted process. But if you ever want to restore the files you have backed up, you will be unable to believe any of the access class labels or kernel data written by backup. In general, backup and restore operations must be implemented within the kernel or as trusted functions (see section 10.5).

REFERENCES

Ames, S. R., Jr.; Gasser, M.; and Schell, R. R. 1983. “Security Kernel Design and Implementation: An Introduction.” Computer 16(7): 14–22. Reprinted in Advances in

Computer System Security, vol. 2, ed. R. Turn, pp. 170–76. Dedham, Mass.: Artech House (1984).

An overview of the reference monitor concept, security models, and kernel implementation issues.

Anderson, J. P. 1972. “Computer Security Technology Planning Study.” ESD-TR-73-51, vols. 1 and 2. Hanscom AFB, Mass.: Air Force Electronic Systems Division. (Also available through Defense Technical Information Center, Alexandria, Va., DTIC AD-758206.)

The first study to document the government’s computer security problem and the proposed solutions in the form of the reference monitor and the security kernel; now no longer useful as a primary technical reference, but historically important.

Berson, T. A., and Barksdale, B. L. 1979. “KSOS—Development Methodology for a Secure Operating System.” Proceedings of the NCC 48: 36571. Reprinted in Advances in Computer System Security, vol. 1, ed. R. Turn, pp. 155–61. Dedham, Mass.: Artech House (1981).

A description of the development and verification techniques used in the Kernelized Secure Operating System research project for the PDP-11 /70.

Fraim, L. J. 1983. “SCOMP: A Solution to the Multilevel Security Problem.” Computer 16(7): 26–34. Reprinted in Advances in Computer System Security, vol. 2, ed. R. Turn, pp. 185–92. Dedham, Mass.: Artech House (1984).

A minicomputer-based security kernel with sophisticated hardware protection controls; this system is a Honeywell product.

Gold, B. D.; Linde, R. R.; Peeler, R. J.; Schaefer, M.; Scheid, J. F.; and Ward, P. D. 1979. “A Security Retrofit of VM/370.” Proceedings of the NCC 48: 335–44.

Describes the KVM security kernel.

Karger, P. A., and Schell, R. R. 1974. “Multics Security Evaluation: Vulnerability Analysis.” ESD-TR-74-193, vol. 2. Hanscom AFB, Mass.: Air Force Electronic Systems Division. (Also available through National Technical Information Service, Springfield, Va., NTIS AD- A001120.)

A discussion of penetrations of Multics, pointing out several classic types of flaws in various areas; useful as a guide to detecting flaws in other operating systems.

Landwehr, C. E. 1983. “The Best Available Technologies for Computer Security.” Computer 16(7): 86–100. Reprinted in Advances in Computer System Security, vol. 2, ed. R. Turn, pp. 108–22. Dedham, Mass.: Artech House (1984).

An overview of all past and ongoing secure system projects, with many references.

McCauley, E. J., and Drongowski, P. J. 1979. “KSOS—The Design of a Secure Operating System.” Proceedings of the NCC 48:345–53. Reprinted in Advances in Computer System Security, vol. 1, ed. R. Turn, pp. 14553. Dedham, Mass.: Artech House (1981).

A description of the design of the KSOS security kernel for the PDP-11.

Popek, G. J.; Kampe, M.; Kline, C. S.; Stoughton, A.; Urban, M.; and Walton, E. J. 1979. “UCLA Secure Unix.” Proceedings of the NCC 48: 355–64.

The UCLA security kernel for the PDP-11.

Schell, R. R.; Tao, T. F.; and Heckman, M. 1985. “Designing the GEMSOS Security Kernel for Security and Performance.” In Proceedings of the 8th National Computer Security Conference, pp. 108–19. Gaithersburg, Md.: National Bureau of Standards.

A description of a security kernel for the Intel iAPX 286 microprocessor offered by Gemini Computers.

Schiller, W. L. 1975. “The Design and Specification of a Security Kernel for the PDP-11/45.” ESD-TR-75-69. Hanscom AFB, Mass.: Air Force Electronic Systems Division. (Also available through Defense Technical Information Center, Alexandria, Va., DTIC AD- A011712.)

Historically important as the first formal specification for a security kernel.

———. 1977. “Design and Abstract Specification of a Multics Security Kernel.” ESD-TR-77- 259. Hanscom AFB, Mass.: Air Force Electronic Systems Division. (Also available through Defense Technical Information Center, Alexandria, Va., DTIC AD-A048576.)

A worked example of a formal specification of a security kernel for a, large operating system (though the system was never implemented).

Chapter 11