The security kernel approach provides controlsthat are effective against most internal attacks-including some

that many designers never consider.

Security Kernel Design andImplementation: An Introduction

Stanley R. Ames, Jr., and Morrie Gasser, The Mitre Corporation

Roger R. Schell, DoD Computer Security Center

Providing highly reliable protection for computerizedinformation has traditionally been a game of wits. Nosooner are security controls introduced into systems thanare penetrators finding ways to circumvent them. Securi-ty kernel technology provides a conceptual base on whichto build secure computer systems, thereby replacing thisgame of wits with a methodical design process. Thekernel approach is equally applicable to all types ofsystems, from general-purpose, multiuser operatingsystems to special-purpose systems such as communica-tion processors-wherever the protection of shared in-formation is a concern.Most computer installations rely solely on a physical

security perimeter, protecting the computer and its usersby guards, dogs, and fences. Communications betweenthe computer and remote devices may be encrypted togeographically extend the security perimeter, but if onlyphysical security is used, all users can potentially accessall information in the computer system. Consequently,all users must be trusted to the same degree. When thesystem contains sensitive information that only certainusers should access, we must introduce some additionalprotection mechanisms. One solution is to give each classof users a separate machine. This solution is becomingincreasingly less costly because of declining hardwareprices, but it does not address the controlled sharing ofinformation among users. Sharing information within asingle computer requires internal controls to isolate sen-sitive information.

Continual efforts are being made to develop reliableinternal security controls solely through tenacity and

hard work. Unfortunately, these attempts have been uni-formly unsuccessful for a number of reasons. The first isthat the operating system and utility software are typical-ly large and complex. The second is that no one hasprecisely defined the security provided by the internalcontrols. Finally, little has been done to ensure the cor-rectness of the security controls that have been im-plemented.The security kernel approach described here directly

addresses the size and complexity problem by limiting theprotection mechanism to a small portion of the system.The second and third problems are addressed by clearlydefining a security policy and then following a rigorousmethodology that includes developing a mathematicalmodel, constructing a precise specification of behavior,and coding in a high-level language.

The security kernel approach is based on the conceptof the reference monitor, an abstract notion adaptedfrom the models of Butler Lampson.I The referencemonitor provides an underlying security theory for con-ceptualizing the idea of protection. In a referencemonitor, all active entities such as people or computerprocesses make reference to passive entities such asdocuments or segments of memory using a set of currentaccess authorizations (Figure 1). Of particular impor-tance is that every reference to information (e.g., by aprocessor to primary memory) or change of authoriza-tion must go through the reference monitor.The security kernel is defined as the hardware and soft-

ware that realize the reference monitor abstraction. Tosuccessfully implement a security kernel, we must adhere

0018-9162/83/0700-0014S01.00 (© 1983 IEEE14 COMPUTER

to three engineering principles: (1) completeness, in thatall access to information must be mediated by the kernel;(2) isolation, in that the kernel must be protected fromtampering; and (3) verifiability, in that some cor-respondence must be shown between the security policyand the actual implementation of the kernel. The com-pleteness and isolation requirements are best addressedwith an adequate hardware foundation. A formal devel-opment methodology can be a powerful tool for address-ing the verifiability requirement.

Schell first introduced the security kernel concept in1972 as "a compact security 'kernel' of the operatingsystem and supporting hardware such that an antagonistcould provide the remainder of the system without com-promising the protection provided." In 1974, Mitretested the hypothesis that such a security kernel could ac-tually be constructed. The first security kernel consistedof less than 20 primitive subroutines that directly man-aged the physical resources and enforced protection con-straints. The entire security kernel contained fewer thana thousand compilable high-level language statementsand ran on a DEC PDP-1 1/45.To demonstrate this kernel, Mitre also constructed a

simple, experimental operating system along with ap-plications for a practical military example. The operatingsystem had a hierarchical file system, cooperating pro-cesses with controlled information sharing, and inter-faces to a few interactive terminals. The operating systemand applications were outside the kernel and could notimpact the information protection provided by thekernel.

Since this initial prototype effort, a number of re-search efforts have dealt with the issues of security kernelconstruction and verification. Today, a few security-kernel-based products are being introduced commercial-ly. One such system, the Honeywell Secure Communica-tions Processor (Scomp), is discussed by L. Fraim2 (seethe article in this issue); others are surveyed by C. Land-wehr3 (also in this issue).

Basic principles

The first step in developing a kernel-based system is toidentify the specific set of protection policies to be sup-ported. A given system is "secure" only with respect tosome specific policy. In a computer system, a well-formed protection policy should identify all the permissi-ble modes of access between the active entities, or sub-jects, and the passive entities, or objects. The externalpolicy that corresponds to the people, paper, andmethods of accessing information in the real world mustbe interpreted in a way that allows the policy to apply tothe internal entities of the computer system.

This requirement-that policy be precisely defined-isa primary distinction between a security-kernel-basedsystem and several other efforts to develop security-relevant operating systems, such as "capability" ma-chines.4 These other systems tend to strive for general-purpose protection, yet do not have any definitivecriteria for what is security relevant. The mechanisms inthese systems essentially provide a computer with specialsecurity features. By contrast, the security-kernel ap-

proach explicitly addresses both policy and mechanism.If general-purpose protection mechanisms are well-defined and augmented to enforce a specific policy,however, they can provide an underlying base for subse-quent security kernel construction.

A formally defined security model. We need to definetwo types of policy: nondiscretionary and discretionary.A nondiscretionary policy contains mandatory securityrules that are imposed on all users. A discretionarypolicy, on the other hand, contains security rules that canbe specified at the option of each user.The protection policy enforced by a security kernel is

encapsulated in a set of mathematical rules that con-stitute a formal security model. Both discretionary andnondiscretionary policies must be addressed by the rulesof the model.

In determining whether the model of a policy is suffi-cient, we need to consider two key issues, which occa-sionally have been a source of misunderstanding. First, amodel of a policy must define the information protectionbehavior of the system as a whole. Merely modeling dis-tinct operations with respect to individual assertionsabout a protection mechanism does not indicate muchabout overall system security and can, in fact, be mis-leading. Second, a model of a policy must include a"security theorem" to ensure that the behavior definedby the model always complies with the security require-ments of the applicable policy.The model enforced by most security kernels has been

derived from early security kernel work at Mitre5 andCase Western Reserve University.6 Commonly referredto as the Bell and LaPadula model, this model providesrules for preventing unauthorized observation and modi-fication of information. By representing the securitykernel as a finite state machine, these rules define allow-able transitions from one "secure" state to the next.

Figure 1. Reference monitor. The security kemel ap-proach Is based on the concept of a reference monitor, Inwhich active entities (subjects) make reference to pas-sive entities (objects) using a set of access authoriza-tions (reference monitor database).

July 1983 15

Within the model, each subject and object of the ref-erence monitor is given a security identifier termed an ac-cess class. The access classes of subjects and objects arecompared at each state transition to determine whether asubject is allowed to access an object. By organizing theaccess classes in the form of a mathematical structurecalled a lattice, a wide range of potential policies can besupported. The lattice defines the relations among accessclasses, allowing us to determine whether one access classis less than, greater than, equal to, or disjoint from (notcomparable to) another. Examples of environments inwhich access classes form a lattice include the privacyprotection compartments of medical data, financialdata, criminal records, and the hierarchical governmentsecurity classifications.

The protection policy enforced by a securitykernel is encapsulated in a set of

mathematical rules that constitute a formalsecurity model.

Of the model's nondiscretionary rules, two are funda-mental. The first, called the simple security condition,states that a subject cannot observe the contents of anobject unless the access class of the subject is greater thanor equal to the access class of the object. This simplesecurity condition prohibits users from directly viewingdata that they are not entitled to see.The second basic nondiscretionary rule, the *-property

(pronounced "star" property) rule, helps to prevent allillicit indirect viewing of objects. It stipulates that a sub-ject may not modify an object unless that object's accessclass is greater than or equal to the access class of thesubject.The purpose of the *-property is to explicitly address

the problem of "Trojan horse" software, which as thename implies is software that appears legitimate but infact is designed to do something illicit in addition to itsnormal function. For example, any generally used soft-ware utility, such as a text editor or compiler, has thepotential for accessing a user's files in a manner the usermight not have intended. A Trojan horse implanted in atext editor could make illicit copies of a user's file andstore the information in a file belonging to an unauthor-ized user, all unbeknownst to the original user.The Trojan horse problem is serious when highly sen-

sitive information is involved, especially on large systemswhere the programmer responsible for a given utility pro-gram cannot always be determined. A person is, ofcourse, charged with the responsibility for maintainingthe confidentiality of information, but a computer utilitysuch as a text editor cannot necessarily be given the sametrust. The reason is that we may have no practical way todetermine whether the utility contains a Trojan horse.With the *-property, information cannot be compro-

mised through the use of a Trojan horse. Under this rule,the program operating on behalf of one user cannot beused to pass information to any user having a lower ordisjoint access class.

The simple security condition and the *-property areprimarily to prevent the unauthorized disclosure of in-formation, but the model also includes integrity proper-ties to protect information from improper alteration. In-tegrity rules prevent subjects with a given integrity classfrom modifying objects of higher integrity or being af-fected by objects of lower integrity.

The nondiscretionary rules of the model do not pro-vide a protection policy that distinguishes different userswithin the same access class. Discretionary rules are in-cluded in the model to provide that type of protectionpolicy. The discretionary rules of the Bell and LaPadulamodel allow authorized users and programs to arbitrarilygrant and revoke access to information based on usernames or other information. Since discretionary controlsare more or less arbitrary, we cannot make very many ab-solute statements about the movement of the informa-tion. In particular, the Trojan horse attack is more dif-ficult to address under these controls than under non-discretionary controls. Therefore, the latter, being muchstricter, always takes precedence.

In addition to the threats of improper disclosure ormodification of information, we have a threat known asdenial of service (e.g., crashing the system or making itunresponsive), which most security models such as theBell and LaPadula model do not explicitly address.While a kernel-based system is likely to withstand thisthreat at least as well as any conventional system, rulesdealing with denial of service are more difficult to for-malize in a model.

Faithful implementation. The mathematical modelaids in identifying the types of functions that a kernelshould provide. It does not, however, specify the designfor the applications interface to the kernel. To bridge thegap between model and implementation, the develop-ment process must be broken into small steps. One com-mon technique is to apply a hierarchy of abstract specifi-cations to the design of the security kernel. For each step,it is important to demonstrate security so that we haveconfidence in the security of the final system.We can use numerous formal and informal methods to

demonstrate security with varying degrees of confi-dence-the reference monitor concept does not mandateany one approach. However, early in the formulation ofthe kernel approach, we recognized that formal specifi-cation and mathematical verification had the potentialfor providing real proof that the implementation of thekernel faithfully followed the rules of the model. Theseformal methods have since been applied to various de-grees in demonstrating the correspondence between themodel, the hierarchy of specifications, and the high-levellanguage implementation (Figure 2).As with any operating system design effort, preparing

the specifications is a creative activity, molded by theparticular design and security goals of the system. Themost abstract kernel specification defines all the kernel'sinterface characteristics. We can use this high-level speci-fication to judge functionality as well as to demonstratethat the interface preserves the rules of the model. Oncethe interface functionality is specified abstractly and itssecurity properties are precisely established, we can ex-

COMPUTER16

pand the functionality by gradually introducing more im-plementation detail. This process is done without affect-ing the validity of the security properties alreadyestablished. (For examples of systems that use formalspecification techniques, see the article by Landwehr inthis issue.)

Three classes of formal verification techniques havebeen applied to different stages of kernel development(Figure 2), and several techniques are available withineach class. The first class is used to prove that thekernel's intended behavior, as described in the formalhigh-level interface specification, is secure with respect tothe policy model. One common technique, securityJflowanalysis, is a relatively simple way to identify and analyzeinformation flows in a specification.7 Note that only thesecurity of the interface specification must be demon-strated, not the more difficult problem of its functional"correctness," since functional properties, most ofwhich are not security related, are not addressed by themodel.

In the second class of formal verification techniques,we verify the correspondence or correctness of mappingsbetween any intermediate specifications in the hierarchyand the interface specifications. Finally, a third class ofverification techniques, the most traditional way toprove correctness, shows that the kernel implementationcorresponds to its specification.

Cheheyl et al. have documented a survey of currentverification systems covering most of these techniques,

Figure 2. Development and verification hierarchy.

along with their application to Department of Defensesecurity policy.8 Walker et al. describe an example of aformal specification and verification.9

Implementation considerations

To successfully realize a kernel-based system, we musttake into account architectural and engineering consider-ations that may not be encountered in the developmentof other systems. Although the kernel approach can beapplied to all types of systems, these considerations arebest illustrated in the context of a general-purposeoperating system with online, interactive users (Figure 3).The kernel, as already noted, provides a relatively smalland simple subset of the operating system functions. Thekernel primitives are the interface of this subset to therest of the operating system (generally referred to as thesupervisor). In turn, the supervisor primitives providethe general-purpose operating system functions used bythe applications.

Kernel/supervisor trade-offs. An operating system isusually broken down into functional areas, such as pro-cess management, file system management for segments,and I/O control. Within each area, some functions areclearly security relevant and must be in the kernel, whilesome are not. The rules of the policy model help to clear-ly identify which functions are security relevant.

Figure 3. Structure of a kernel-based operation system.

July 1983 17

The kernel must handle the parts of an operating sys-tem that manage resources, such as memory and diskspace, shared by multiple users. These parts are in thekernel because the model requires that these resources bevirtual to hide their location from untrusted (nonkernel)software. The functions that provide useful commonutilities but do not manage anything shared among usersand those that address denial of service are outside thescope of the security policy and can generally be in thesupervisor.

In practice, we can usually apply the details of themodel and a particular security policy to determine whatmust be in the kernel and what must be in the supervisor.However, issues such as performance and functionalityoften force us to consider engineering problems thatnecessitate putting non-security-related functions in thekernel. We might have trouble, for example, separatingthe operating system's file-name interpretation mecha-nism, which may not be security relevant, from the ker-nel's file management system. We must constantly maketrade-offs among performance, functionality, and com-plexity when designing a kernel-based system. Trade-offsare especially important when the system is emulating apreviously existing operating system whose functionsmay not be easy to reallocate.

The kernel must handle the parts of anoperating system that manage resources

shared by multiple users.

Trusted subjects. Most systems require a securitypolicy that is more specifically tailored to their needsthan that defined by the basic security model. This tai-lored policy is generally exercised on a limited basis forinfrequent operations and may apply only under specialcircumstances or to a special class of users. A kernel thatimplements such an extended policy will usually providea set of interfaces that can be invoked only by certaintrusted subjects (Figure 3), that is, software it recognizesvia some internal identifier, such as a privilege indicator.When a running program has such privileges, it may beable to perform actions not permitted by the accesschecks built into normal kernel functions.

Trusted subjects usually perform system maintenanceand are needed to control the access policy that the kernelenforces for untrusted subjects. For example, a securityofficer must be given access to maintain the table that thekernel uses to specify access classes of users. Software thesecurity officer uses for this purpose is a trusted subject.Sometimes normal users invoke certain trusted subjectsto perform security-sensitive functions. For example,since the basic security model does not allow an un-trusted subject to lower the access class of information,the occasional need for downgrading a segment that auser accidentally overclassifies is satisfied by providing atrusted subject for the user.

Trusted subjects are often implemented as asynchro-nous processes, called trusted processes, or as extensionsof the kernel itself, called trusted functions. Regardlessof the implementation technique, trusted subjects must

adhere to the same engineering principles as the kernel ifthe security policy is to be correctly implemented. Otherthan the implementation technique, the only difference isthe specific security policy enforced.

Hardware/software features. The kernel approachmay need considerable hardware support to achieveadequate performance. The amount of hardware sup-port is bounded by two extremes. At one extreme, thekernel can be built entirely in software on any conven-tional machine so that the kernel runs as a pure inter-preter, executing and checking every user instruction andpermitting no direct user execution of hardware instruc-tions. In this case, no particular security demands areplaced on the hardware architecture other than the re-quirement to execute the kernel software correctly. Atthe other extreme, all the kernel functions can be imple-mented as hardware instructions; in this case the hard-ware architecture would be completely responsible forsecurity. As with the supervisor/kernel trade-offs, thespecific choices are heavily influenced by the trade-offsamong complexity, size, and performance. In this article,we examine only a pragmatic middle ground, one close toa traditional view of the functional division between thehardware and the operating system software.The hardware features and software mechanisms nec-

essary for a kernel-based operating system to performadequately are sophisticated but not exotic. The specifichardware features desirable for a kernel-based system areprovided in many (but by no means all) modern com-puter architectures, from microprocessors to main-frames. Several past and ongoing kernel implementa-tions have resulted in significant performance degrada-tion from the lack of adequate hardware. However, withappropriate hardware, we see no reason that a kernel-based operating system should perform any worse than anon-kernel-based system with similar capabilities. R.Schell gives a specific example of the features necessaryto implement a microprocessor-based kernel in anotherarticle in this issue. 10

There are four general architectural areas in whichspecific hardware and software mechanisms have proveduseful or necessary to support a kernel-based general-purpose operating system (for special-purpose kernels,some of these mechanisms might be less appropriate):

* explicit processes-efficient support for multipleprocesses (multiprogramming) and interprocesscommunication;

* memory protection-large segmented virtual mem-ory, access control to memory, and explicitly identi-fied objects;

* execution domains-minimum of three states or do-mains (user, supervisor, and kernel) and efficienttransfer of control between domains; and

* I/O mediation-control of access to I/O devices, toexternal media, and to memory by I/O processors.

Although most of these mechanisms are familiar internalcomponents of many current commercial operating sys-tems, their impact is quite hidden from the users, andthey are usually of interest only to system designers.

COMPUTER18

Explicit processes. The reference monitor's notion of asubject is traditionally realized in most operating systemsas a process that operates as a surrogate for some user.The user's identification and access class must thereforebe represented within the system as nonforgeable (andunalterable) identifiers tied to each process. 1lhe iden-tifiers become the basis for making access decisions withrespect to discretionary and nondiscretionary policies.By process we mean the activity of a processor carrying

out the computation specified by a program, the pro-cessor being either a computation or I/0 processor. Forinformation protection to be meaningful, an on-line en-vironmnent must of course include multiple users, so thekernel must support multiple simultaneous processes.This requirement mandates that the kernel save and re-store the representation of a process in execution, other-wise known as the state of the processor. Depending onwhen a process is allowed to be suspended, this state mayinclude the internal state of the CPU, the user-visibleprocessor registers, or merely the instruction counter. Inaddition, the architecture must provide a means of sav-ing and restoring a definition of the accessible informa-tion (i.e., the address space) distinct for each process.The address space is typically defined by a set of de-scriptors, as we discuss later in the section on memoryprotection.

Because of the multiplicity of simultaneous processes,a kernel-based operating system typically has a largenumber of process switches, and an efficient process-switching mechanism is desirable. This mechanism canbe supported in a number of ways: we can use high-speedmemory instead of explicit processor registers, or we canload and store processor registers as a block or even haveseveral independent sets of registers in the processor. Theefficient switching of address spaces can be aided by us-ing a descriptor base or root register instead of copyingmemory descriptor tables, or by simultaneously retainingseveral sets of descriptors.

In addition to the multiprogramming support, we needdirect support for interprocess communication. Par-ticularly for multiprocessor configurations, we need arace-free communication mechanism (e.g., read-alter-rewrite memory access) as well as a processor-to-process-or interrupt capability. Note that an I/0 initiation in-struction is primarily a mechanism for directing an inter-rupt to an I/0 processor. More sophisticated hardwaremechanisms, such as operations to assist process syn-chronization, can also contribute to kernel simplicity andperformance.

Memory protection. The reference monitor abstrac-tion of a storage object is usually realized by memory,and this realization is constrained by the principle ofcompleteness identified earlier. Clearly, some fundamen-tally interpretive mechanism is needed to completelymediate all access to memory. Virtual memory is com-monly used to accomplish the needed mediation. In a vir-tual memory system, some form of descriptor is used tocontrol the access to memory. There must be no way out-side the kernel for a process to access memory withoutusing a descriptor.

With a reterence monitor, all information within thesystem must be represented in distinct, identifiable ob-jects. In all but the simplest case, the virtual addressspace of a process includes more than one object, eachwith distinct logical attributes such as size, access mode,and access class. This logically distinct memory is com-monly called a segment.

With a reference monitor, all informationwithin the system must be represented in

distinct, identifiable objects.

Hardware-supported segmentation of virtual memoryis the underlying mechanism to support this concept.Each segment is identified by a descriptor that controlsthe virtual-address-mapping hardware. The descriptorcontains some logical attributes as well as a physical baseaddress and a segment size (or bound) to distinguish eachsegment. Complete access mediation is provided, sincefor each access to virtual memory the hardware must in-terpret the relevant descriptor.Two factors are quite important in supporting an effi-

cient and simple secure system: (1) each process shouldbe able to have a relatively large number of independentsegments, and (2) any segment should have a wide rangeof possible sizes. These requirements tend to result in alarge number of segment descriptors for each process. Ahigh-speed associative cache memory can be useful tospeed address translations without requiring software toreload descriptors on each process switch.

Architectures in which a process's view of virtualmemory is not segmented but is simply a large, linear ad-dress space, with no portion shared by other processes,are often compatible upgrades to older systems withoutvirtual memory. Although kernel-based systems can beand have been built on such architectures, considerableflexibility (and resulting performance) can be lostbecause of the inability to directly address differentsegments with differing access rights.To implement typical discretionary and nondiscre-

tionary access policies of the reference monitor, the seg-ment descriptor must support distinct access modes of atleast null, read, and read-write for each segment.

Overall system performance can often be enhanced byincluding a referenced and modified flag for each blockof physical memory. This enhancement permits more ef-ficient operating system memory management schemeswhen information must be moved back and forth be-tween primary memory and secondary storage.The segment descriptors are, of course, managed by

the security kernel software, although much of the actualmediation of the reference monitor is performed by theaddress-mapping hardware. Since address mapping re-quires an examination of the descriptors, the hardwarecan conveniently check access using information in thedescriptor at the same time with no additional perfor-mance penalty. The security kernel software enforcesreference monitor authorizations by controlling the ac-cess mode specified in the descriptors for all segments ofeach process.

July 1983 19

Even if all access to segments is fully controlled, thekernel designer may encounter a major pitfall: the possi-bility that information will be leaked unintentionallythrough the use of control information. Control infor-mation consists of items that are not memory objects inthe usual sense but are shared repositories of informa-tion. They include items maintained within the kerneldatabase, for example, file names and attributes, systemvariables such as the number of users logged in, and thesizes of message queues. Although these items are notwithin the hardware-supported virtual address space,they are objects to the reference monitor, and thus thekernel must mediate access to each of them in the sameway that it controls access to segments. Access to most ofthese items is usually done interpretively through explicitkernel calls, rather than through hardware.Any accidental leakage of information through the use

of control information should, of course, be detected byappropriate design and verification techniques. The pit-fall is the possibility that some fundamental aspect of thedesign is based on (and in fact may depend on) this leak-age. This issue must be recognized early in the designbecause at a late stage of system development, the re-moval of undesired leakage channels can be one of themost difficult tasks a kernel designer can encounter.

Execution domains. Execution domains are essentialto the isolation and protection of the security kernelmechanism. The total address space of a process includesthe programs and data of the security kernel, since thesemust clearly be accessible when the security kernel func-tions are invoked. Yet, the kernel also requires a distinctexecution domain so that a process can access some ob-jects (most notably the segment descriptors) only whenexecuting in the kernel itself.

The simplest and most common domain structure ismade up of two hierarchical domains implemented byprivileged and nonprivileged modes of processor execu-tion. The privileged domain contains only the kernel. Al-though two domains are sufficient to protect the kernel,the supervisor would have to reside in the same domainas the applications software-a serious limitation. Oper-ating systems traditionally reside in the privileged do-main while the user applications do not. Thus, to retainthe benefits of separating the operating system from theuser, we need a minimum of three hierarchical domains:kernel, supervisor, and user.More general nonhierarchical domains could be useful

in simplifying the design of a kernel-based system. Do-main and capability machines fall into this class. Workon using a more general domain structure for kernel de-velopment is now in the research stage.A process typically experiences a large number of calls

to the kernel and supervisor, so we want mechanisms thatease the transfer of program control between domains.Entrance into the most privileged domain must, ofcourse, be limited to well-defined entry points. A com-mon means of limiting entrance is by using a system orsupervisor fault or trap that transfers control to a knownlocation. However, kernel simplicity and efficiency areimproved if the hardware supports multiple entry pointsin a fashion more like a procedure call, so that each

kernel function has a distinct entry point. The hardwareshould also support some form of argument validation(i.e., checking the validity of arguments passed by the ap-plication or supervisor to the kernel) and stack manage-ment for cross-domain calls. The Multics system employsa particularly elegant and efficient hierarchical domainarchitecture with domain-crossing hardware.1I

Input/output mediation. I/0 in most machines cantake place in two fundamentally different ways. Thesimplest way, often called "programmed I/O," requiressoftware to explicitly execute an I/0 instruction totransfer each byte or word of information between anI/0 device and a register or memory. We must thereforeconsider I/0 devices as objects within the referencemonitor framework; thus the kernel must control accessto these devices. Typically, we would restrict the use ofI/0 instructions to the most privileged software domain(i.e., the kernel), and allow user and supervisor softwareto invoke kernel functions to perform I/O on theirbehalf.A more complex architecture for I/O provides inde-

pendent I/O processors that, once activated by the cen-tral processor, asynchronously transfer information be-tween devices and memory. This transfer of informationis specified by an explicit I/0 program residing in mem-ory or an implicit program (one built into the I/O pro-cessor) that is given parameters such as buffer and deviceaddresses. The kernel must consider I/0 programs in ex-ecution, or I/O processes, as subjects, and it must there-fore control access to memory by I/O processors in thesame manner as it controls access to memory by theCPU. As in programmed I/O, the conventional ap-proach to handling this access control is for hardware tolimit initiation of I/O processors (e.g., execution of astart I/0 request) to the most privileged domain. I/O re-quests made by a user are in the form of kernel functioncalls. These calls cause a check of the I/O program or pa-rameters to ensure that both the I/O devices and memorysegments containing the I/0 buffers are accessible to theuser. The I/0 processor itself, usually lacking multipledomains, typically works entirely in the kernel domainand uses physical memory addresses supplied by thekernel. Consequently, the kernel must often translatevirtual addresses in the I/O program to physical ad-dresses. Because of the sophisticated capabilities of someI/0 processors, kernel checking of user-defined I/O pro-grams can be a complex function.

Because of the complexity of handling I/O, a hard-ware architecture that allows direct user or supervisor do-main access to I/0 is desirable. Such an architecturewould provide some form of descriptor to control accessto the devices, in a manner similar to the use of memorydescriptors. In addition, for the I/O processor to effec-tively operate outside the kernel by accessing virtualmemory on behalf of the user, we need descriptor-con-trolled access to memory by the I/O processor. Such acapability is provided by the Scomp as discussed in thearticle by Fraim, which appears in this issue.A careful concept of I/O operation should be part of

the kernel development effort. We need to clearly distin-guish between two device types: (1) external I/O involv-

COMPUTER20

ing devices such as terminals, local printers, and tapedrives, which are effectively accessed by only one user ata time, and (2) internal l/O that includes devices such asdisk drives and their storage media, which the kernelmust manage because they can access information com-mon to multiple users. For all removable I/O media onexternal devices capable of accessing information withvarying access classes, we need a trusted labeling tech-nique to ensure that the access class of the medium is cor-rectly marked, or that some operator is in control of theaccess class of information accessible to the device. La-bels can include, for example, nonforgeable bannersheets on printer output and operator interaction withthe kernel for mounting tapes and removable disks.

Verification. Most kernel developments to date havebeen accompanied by some degree of formal verifica-tion. Some of the early promises of formal verificationwere overstated-verification has turned out to be moredifficult than we expected.12 Formal verification of akernel involves problems of program correctness, and weare still quite a long way from being able to prove the cor-rectness of a large computer program. Because formalverification technology has not fully matured, we need tounderstand its current capabilities before defining re-quirements for a major kernel development. Unrealisticexpectations for verification can turn a practical develop-ment effort fully within the bounds of current technol-ogy into a research effort that could consume unlimitedresources.

Many traditional nonmathematical methods such asstructured design and testing can contribute to the over-all confidence in the security of the kernel. With realisticgoals, formal verification can enhance these traditionaltechniques and play a major and useful part in the kerneldevelopment process. Of the various stages of kerneldevelopment to which verification can be applied, thegreatest degree of success has been obtained in specifica-tion verification. We have several techniques for verify-ing a formal specification against its model, and some ofthese, such as the flow analysis method mentioned ear-lier, have become almost routine. We can also verify cor-respondence between intermediate levels of specifica-tions. However, even if there is no intent to complete afull mathematical proof, we still have the rigorous re-view, documentation, and kernel-development guide-lines that most verification methodologies enforce.These alone will ensure a more secure and reliablesystem.

Although total confidence in the security of a system isnot yet achievable, we can specify degrees of confidencein the security of different systems. The Department ofDefense has recently promulgated a set of Trusted Com-puter System Evaluation CriteriaI3 that define severaldistinct evaluation classes of progressively increasingconfidence. These criteria explicitly recognize the valueof following most of the security kernel design principleswe have identified, yet they have widespread applica-bility to most types of systems, kernel-based or not.

Power lhne problems? No problem.Analyze them withSTABILINEO ACVoltage Monitors ...Truly portable multi-site disturbance

analyzers - the only systems withdetachable, microprocessor basedDetector Modules which can be

_5 t left at each site. Depending on_ ~~~~~~~whether 1- or 3-phase models

are selected, Printer/Controllerscan provide categorized formats of

high/low voltages, surges, sags, impulses,common-mode noise, dropouts, power outages, d-c voltage,voltage and angle unbalances. Summaries include date, time,magnitude and duration of each category's 10 worst eventsand a list of the last 10 chronological events that qualify bythreshold. Detector Modules can communicate with Printer/Controllers directly or over conventional telephone lines withsuitable interfacing. Models available for 120, 240 or 480 VAC.

0-383 Middle Street / Bristol, Connecticut 06010/ (203) 582-9561 / Telex: 9tIN EUROPE: Superior Electric Nederland B.V

The Hague, Netherlands / (070) 679590/ Telex: 31436 SulIN CANADA: The American Superior Electric Company, Ltd.

Toronto, Ontario/ (416) 255-2318/ Telex: 06-967806

Solve them with STABILINE'Voltage Conditioning Equipment. . .Once the problem has been pinpointed, condition aberrationsthat create malfunctions and erratic behavior: Transient Volt-age Suppressors reduce the magnitude of (attenuate) voltagespikes or transients; Automatic Voltage Regulators deliver con-stant output voltage regardless of input line variations; Com-puter Regulators maintain properly conditioned voltage andattenuate common-mode noise and impulses; Power Condi-tioners regulate voltage, provide isolation for common-modenoise and reduce transverse-mode noise; Transient Suppressors/Voltage Regulators combinevoltage correction and impulseattenuation; Isolation Trans-formers isolate equipmentfrom common-mode noisegenerated by power consum-ing devices.

Write or call forSTABILINE _literature.

Reader Service Number 3

The security kernel design approach is the most prom-ising methodology currently available that can provideboth the internal security and the functional capabilitiesthat many of today's computer systems need. This ap-proach is based on a firm foundation and will support awide range of commercial and governmental informa-tion protection policies. The kernel provides securitycontrols that are effective against most internal at-tacks-including many that kernel designers never con-sidered. Bugs of malicious software contained in applica-tions, or even in the operating system, cannot cause un-authorized access to information.The overall trend in hardware and software technology

for computer systems is toward greater application of theprinciples and features applicable to the kernel ap-proach. We have in fact recently seen the emergence of asecurity kernel in a commercial product (HoneywellScomp). The required hardware and operating systemtechnology is thus clearly within practical application.M

References

1. B. W. Lampson, "Protection," Proc. Fifth PrincetonSymp. Information Sciences and Systems, Mar. 1971, pp.437-443.

2. L. Fraim, "Scomp: A Solution to the Multilevel SecurityProblem," Computer, Vol. 16, No. 7, July 1983.

3. C. Landwehr, "The Best Technologies for ComputerSecurity," Computer, Vol. 16, No. 7, July 1983.

4. R. M. Needham and R. D. H. Walker, "The CambridgeCAP Computer and Its Protection System," ACM

Positions available In

EOMRLIER& rQUTICfor graduates In

MathematicsComputer ScienceElectrical EngineeringMechanical EngineeringOpportunitie In programming and engineering* VLSI doign * Multp large networks* Supercomputer architectures 0 Personal computen* Robotic systems and control * Unix and VMS enhancemente Artficial Intelligence * Network operating systems* Expert sydoms 0 Multi-media mossago systems

Intelligent management systems * Progromming envionmentsImageand speech processing * Grophics applicatons

Send resumes to;Director of Research FacilitiesComputer Science Department

[11!]CornegeMeuon CarnegiMellon UniversitylJCornegeMeon Unrwsitv Pitsburgh, PA 15213_Zwasw/mo0-_ (412) 575.2591

Operating Systems Review, Vol. II, No. 5; also in Proc.Sixth Symp. Operating System Principles, Nov. 1977, pp.1-10.

5. D. E. Bell and L. J. LaPadula, "Computer SecurityModel: Unified Exposition and Multics Interpretation,"tech. report ESD-TR-75-306, AD A023588, The MitreCorporation, Bedford, Mass., June 1975.

6. K. G. Walter et al., "Structured Specification ofa SecurityKernel," Proc. 1975 Int'l Conf. Reliable Software, IEEECat. No. 75CH0940-7CSR, Los Angeles, Calif., Apr.1975, pp. 285-293.

7. J. K. Millen, "Operating System Security Verification,"Case Studies in Mathematical Modeling, W. E. Boyce,ed., Pitmann Publishing, Marshfield, Mass., 1981, pp.335-386.

8. M. H. Cheheyl et al., "Verifying Security," ACM Com-puting Surveys, Vol. 13, No. 3, Sept. 1981, pp. 279-339.

9. B. J. Walker et al., "Specification and Verification of theUCLA Unix Security Kernel," Comm. ACM, Vol. 23,No. 2, Feb. 1980, pp. 118-131.

10. R. R. Schell, "The Structure of a Security Kernel for aMultiprocessor Microcomputer," Computer, Vol. 16,No. 7, July 1983.

11. M. D. Schroeder and J. H. Saltzer, "A Hardware Ar-chitecture for Implementing Protection Rings," Cbmm.ACM, Vol. 15, No. 3, Mar. 1972, pp. 157-170.

12. "Verification of Secure Software Systems," Proc. 1980Symp. Security and Privacy, IEEE Cat. No. 80CH1522-2,Apr. 1980, pp. 157-166.

13. Trusted Computer System Evaluation Criteria, DoDComputer Security Center, Ft. Meade, Md., Jan. 1983.

Stanley R. Ames, Jr., is guest editor of this special issue on com-puter security technologies. His photo and biography appear onp. 12.

Morrie Gasser is a group leader at TheMitre Corporation in Bedford, Massachu-setts. Since 1971, he has been involved inmost aspects of computer security includ-ing hardware and software design and im-plementation, formal specification andverification, and computer security appli-cations. His role at Mitre includes both in-house design and development as well asconsulting to the Department of Defense

on various research and development programs. Gasser re-ceived a BA in physics in 1969 from the University of Chicago.

Roger R. Schell is a colonel in the UnitedStates Air Force and is currently assignedas the deputy director of the Departmentof Defense Computer Security Center, Ft.Meade, Maryland. His interests includeoperating systems, software engineering,and computer security. From 1978 to1981, he was associate professor of com-puter science at the Naval PostgraduateSchool in Monterey, California. Other ex-

perience includes serving as program manager and softwareengineer for several large military software developments, de-signing and implementing a dynamic reconfiguration for a com-mercial operating system, and introducing the security kerneltechnology.

Schell received a BS in electrical engineering from MontanaState College, an MS in electrical engineering from WashingtonState University, and a PhD in computer science from theMassachusetts Institute of Technology.

COMPUTER22