• About ISSO
• Research Areas
• Projects
• Finished Projects and Archive
• Opensource Projects

Finished Projects

Security Infrastructure

Extensible Operating System Security

Extensible OS Security is a research project funded by DARPA's Information Technology Office (ITO). This page provides the basic project summary information required by ITO for all of its research projects. View the quad chart graphic for this project.

ARPA Order Number:	F207
Principle Investigators:	Dennis Hollingworth
Contractor:	TIS Labs at Network Associates
Title of Effort:	Extensible OS Security

Objective:
This project addresses security issues associated with dynamically extensible operating systems with specific emphasis on dynamic kernel extensibility. The extensible system paradigm constitutes a likely evolutionary path for future high-performance COTS systems that can be adapted to user application requirements. The project is addressing the issue of how to dynamically extend a kernel without violating a system security policy. The result of this research will be to provide a foundation for security policy support in extensible systems and will influence the evolution of COTS system development efforts that support kernel extensibility as a mechanism for enhancing application performance.

Approach:
This project explores concepts involved with the definition and implementation of a viable security model for extensible operating systems. It focuses specifically on the SPIN extensible operating system developed at the University of Washington because SPIN introduces a level of operating system extensibility not previously encountered in operating system development efforts. Specifically, the core system functionality in SPIN is characterized as little more than a mechanism for loading and executing extensions.

The approach being taken by the EXOS project involves exploring the viewpoint that, for extensible systems, kernel-level security support is essentially orthogonal to user-level security support except for user-level policies that involve the control of information flow. Kernel-level security focuses on confinement and least-privilege of kernel functionality, while user-level policies involve role-based access controls, multi-level security support, conflict-of-interest, as well as other aspects of access control. Normally, the kernel is included as part of the trusted computing base, but the introduction of user-level kernel extensibility requires rethinking of the nature of the TCB because of the mutability of the kernel/user boundary.

This project is addressing two different policy requirements for the SPIN system. The first requirement is the need to support important user-level security policy models found in the government and private sectors. These include Multi-Level Security, Role-Based Access Control, Chinese Wall, and Clark-Wilson. Specific approaches as well as policy specification language primitives and operating system primitives useful for supporting these policy models are being identified.

The second requirement involves supporting a policy that confines and protects user and system extensions that are loaded into the kernel. The SPIN kernel, as well as user-defined kernel extensions loaded into the kernel address space, are implemented in a modified, pointer-safe variant of the Modula-3 programming language. In the standard SPIN system, this results in the equivalent of a single, linked code image. In effect, the SPIN kernel, with included extensions, is one large program. The project is investigating the means by which the analogue of user virtual address space protection might be efficiently applied to the SPIN kernel. Specifically, the project has identified kernel-level enhancements that apply a confinement and least-privilege policy to the kernel itself. The latter are based on the concept of mechanisms that structure the kernel into identified segments and associate segment access rights with security domains and type enforcement. These mechanisms are useful both for addressing the interrelationship of user-level and kernel-level security interactions as well as protecting the kernel itself from the effects of potentially misbehaving kernel extensions.

A fundamental concept that we are exploring is that of security domains. Extensible systems require an access control mechanism that is orthogonal to the user or authority that spawns a task. In traditional systems, a common model is that of a thread executing on behalf of a user request. Access control decisions are made based on the user's identity. However, in the SPIN extensible OS, there is an additional security objective. As the thread executes, it may progress through several different extensions, each of which has different security requirements. For example, a thread may execute device driver code that has special privilege and needs to be protected from tampering, or it may execute server code that has no special privilege but still needs to be protected from outside tampering. Hence, there is a requirement to provide security separation between these extensions as well as the core system functionality itself. Security domains can be utilized to constrain the allowed and denied access modes associated with the thread as it follows its execution flow.

Unlike classical systems, which provide for the isolation of user-initiated threads, security domains provide for the isolation of system components. In addition, security domains confine the effects of potentially misbehaving or subverted system components. Security domains:

• help preserve the integrity of the operating system by structuring the OS so as to minimize privilege and isolate components from one another, and
• help support user-level security requirements through their support of specific user-level security functionality such as role-based access control and well-formed transactions.
• Another concept we are investigating, that of object kind, addresses the need for access control at a very fine-grained interface level in comparison to conventional systems. An extensible system will export interfaces that previously would only exist as part of the internals of a conventional kernel, i.e., at a much finer granularity than the typical OS API. Therefore, in such systems we need to control access at a much finer granularity and have devised methods of introducing fine-grained access controls on the exported method or procedure level.

A final concept, that of segments, offers the opportunity to separate one part of an address space from another without reliance upon hardware mechanisms while still leaving an opportunity to utilize hardware mechanisms when performance and protection requirements coincide. This mechanism allows an extension to protect a section of memory from unwanted reading, writing or execution.

In order to implement the security domain concept and to enforce access controls on these domains, there must be sufficient low-level protection mechanisms to:

• compartmentalize kernel code into separate segments with different security characteristics.
• allow the system to determine in what domain a thread is executing before any security relevant procedure call.
• mediate and enforce access control decisions when a security relevant procedure call is made, preferably in a manner that is transparent to the callee and caller.

Two different protection mechanisms that can support these goals are being explored:

• per-thread dynamic link tables
• procedure call interposition

Per-thread dynamic link tables and procedure call interposition provide efficient fine-grained access control to procedure calls and data access. The primary difference between the two mechanisms is a strength of mechanism vs. performance tradeoff. Per-thread dynamic link tables can be used to allow or disallow the current executing thread access to a procedure call. This mechanism involves minimal checking when the procedure call is being made. The penalty is paid in setting up the allowed and disallowed access modes. The performance goal of this mechanism is to minimize the overhead of security enforcement at procedure call time. Thus, this mechanism attempts to optimize the common operation, procedure calls, at the expense of the less common operations, domain changes and access decisions. As a consequence, this technique does not allow access control on procedure call invocation based on the procedure's arguments.

In contrast, the procedure call interposition mechanism involves a much greater overhead at procedure call time but introduces a much greater level of flexibility than per-thread dynamic link tables. This mechanism allows for a very wide range of access checks to be made at procedure invocation time. These access checks can depend on both the procedure call being made as well as the arguments to the procedure call itself. This flexibility comes with a significant performance penalty on a potentially common operation, the procedure calls being controlled.

Recent Accomplishments:
Recent project efforts have focused on investigating classical as well as recent work in security policy specification and support to determine how best to address SPIN system security needs. Four major user-level policy models were selected as important policy models that should be supported by the SPIN security architecture: MLS, RBAC, Clark-Wilson, and Chinese Wall. Specific policy models were selected to clearly establish how important security policies can be supported through designed policy specification and enforcement mechanisms. These policy models are widely recognized as addressing important government as well as commercial security requirements. In addition, an approach was developed for supporting kernel-level security policy goals involving enforcement of kernel and extension confinement requirements as well as least-privilege-based system structuring that utilizes concepts developed under prior DTE research conducted at TIS Labs. The approach is based upon the establishment and enforcement of security domains during kernel code execution. Code regions involving specific kernel or user-introduced extension functionality are organized into segments which can only be accessed by selected domains.

Current Plan:
The research plan developed for this project involves a multi-phase effort over 30 months. The first phase of the effort focuses on concept development, exploration and refinement with respect to specification and enforcement of a system-level security policy that addresses kernel extensibility requirements. It includes definition of a security architecture for the SPIN system, and definition of a policy specification language that covers both kernel-extensibility as well as specific important user-level security policy models. It focuses on the need for security concepts that support introduction of user-supplied extensions into the SPIN kernel. The kernel extensibility policy is predicated upon the concept of treating thread/domain pairs as security subjects as defined in classical security techniques and employing DTE-like domain/type access control ckecks for kernel-based security policy enforcment.

The second phase of the project has been funded as a technical option and will demonstrate how to implement an extensible kernel in such a way that the extensions are subject to the security policy. This work involves identifying appropriate software and possibly hardware techniques for supporting the specification and enforcement mechanisms that provide a foundation for implementing the concepts defined during the first phase of the project. The project will implement the TCB policy enforcement mechanisms by building upon the currently existing compile, link and load time mechanisms that a target extensible system uses to constrain kernel extensions and to protect the core kernel from tampering. Project plans involve developing supporting software mechanisms based on per-thread dynamic link tables to support software-implemented segments that provide least privilege and confinement support for selected kernel and extension functionality.

Technology Transition:
There are two aspects of the technology transfer effort identified for the EXOS project. The first is near-term and internally-oriented and is tied to specific project objectives involving code transfer to the SPIN source tree. The second aspect potentially extends outside the boundaries of the project and potentially beyond the lifetime of the project. It involves communication and publication of research results and exploration of the application of the work to internal NAI product development efforts.

Intra-Project Technology Transfer Activities

The focus of the TIS Labs EXOS project involves defining and introducing security functionality into the University of Washington SPIN extensible operating system. As such, the project is intimately dependent upon the SPIN OS development work performed by the University of Washington. The near-term aspect of the technology transfer process involves making our SPIN OS enhancements and research results available to the University of Washington SPIN development effort as well as other researchers. To accomplish this, we will introduce our changes into the SPIN distribution tree, either directly, with the support of the University of Washington, or indirectly by introducing the changes in a parallel and public distribution tree supported through TIS Labs.

Extra-Project Technology Transfer Approach

The external aspect of the technology transfer process comes from the applicability of the software protection technology research results to ongoing external research activities into software-based protection as well as future NAI development activities. Current research thrusts in JAVA, ActiveX, Active Nets, and other efforts depend upon software approaches rather than hardware approaches to security and protection and are based upon strongly-typed languages, software fault isolation, and other techniques. The SPIN effort addresses the provision of fine-grained software protection through pointer-safe enhancements to a strongly-typed language, i.e., SPIN-enhanced Modula-3. Since the SPIN security work is predominantly software-based, it will potentially be applicable to these other research thrusts. Publication of a technical paper or journal article will make our research results available to other outside efforts.

Network Associates is actively acquiring, integrating, and developing new security technology for its product line. These products are essentially network appliances based upon commodity operating system platforms. They include firewalls, sniffers and network analyzers, intranet intrusion protection products, and others. Gigabit network speeds and above, such as supported through Gigabit Ethernet and ATM hardware, require applying new OS paradigms and rearchitecting such appliances to support the much higher traffic processing demands inherent in these high-speed networks. (ATM at OC-3 speeds can fill a 16 MB buffer in one second.) Flexibility requires that such appliances can be changed rapidly to accommodate new software requirements and extensions. NAI is already addressing this to some degree in just-announced firewall technology that supports a "plug and play" model for introduction of new firewall proxies as well as adaptive proxies to improve firewall performance under its Active Security Initiative.

We believe that the DARPA-sponsored new OS paradigm work represented by SPIN, Scout, and Exokernel represent candidate OSs for such appliances. Scout and Exokernel are already being employed in DARPA-sponsored projects associated with ATM-speed firewalls and active network nodes, respectively. Rapid dynamic, functionality- or performance-enhancing software changes make the SPIN technology (although, for pragmatic reasons, probably not the Modula-3 language itself) also applicable to these product efforts. Information about these research efforts and technology results is now being communicated to NAI product managers through regularly scheduled TIS Labs reviews, the first of which took place in June of this year. Our plan is to promote cooperation and mutual participation in future reviews in November and beyond and encourage follow-up design team meetings focused on NAI product development efforts. We will also offer to review design and interface documents associated with identified product development efforts of interest, the first of these being the SuperPod sniffer development effort and proposed HyperPod concept suggested by TIS Labs. The goal is to encourage the transfer of DARPA-funded new OS concepts and technologies directly into the NAI product line to the mutual interest of both organizations.