RTC Magazine

Complex systems are designed and implemented in layers. In secure systems, trust is distributed among those layers. When security components are first assembled into layers, their resulting security properties can be determined and those layers then constructed into systems. This is an important element of the certification and accreditation process needed for secure systems. The Multiple Independent Levels of Security (MILS) architecture was designed to preserve the integrity of the layers in a complex system and to tightly control interaction among them.

This architecture has three layers: the separation kernel, the middleware and the applications. The separation kernel is very small and it’s simple to make it robust and evaluatable. It is also well understood in the MILS community. In contrast, the MILS middleware layer is extensive and much more complex, especially in distributed systems. The purpose of this article is to explore that layer. MILS middleware functions for distributed systems can be grouped into three categories:

• Operating system (OS) services

• Partitioning communications system

• Network middleware

Operating System Services

In traditional architectures with monolithic kernels, system services such as device drivers, memory management, I/O primitives, file systems and network protocol stacks are part of the kernel and run in privileged (supervisor) mode. These services are not part of a MILS separation kernel—they are moved to the middleware layer where they run in unprivileged (user) mode.

This difference is important. When OS service code runs in privileged mode, there is no restriction on what it can do. Privileged code can potentially violate the security policy. Therefore, rigorous examination and testing are required to verify that the code does not violate the policy, even indirectly. The level of effort required to perform this verification escalates rapidly as code size and complexity grow. The MILS separation kernel rigorously enforces four fundamental security policies: data separation, control of information flow, periods processing and damage limitation. Because MILS OS services run in user mode, code that was previously able to violate these policies is now strictly subject to them. Evaluation and certification are more straightforward and effective.

MILS OS services can be implemented in a number of useful ways. They can become part of guest operating systems, reside in dedicated partitions, or be organized as minimal libraries. A system can use all of these implementations simultaneously.

The industry paradigm of “reuse, don’t reinvent,” makes it probable that the application code in a MILS partition was originally developed for another OS such as Windows, Linux, or VxWorks. An adaptation to their hardware abstraction layer (HAL) can cause these operating systems to “see” the separation kernel as the processor, becoming the separation kernel’s “guest.” A guest OS runs in user mode MILS partition, working only with the memory and constrained to the CPU time budgets that have been configured for that partition. This symbiotic relationship between the minimal MILS separation kernel and a fully featured guest OS has several benefits:

• Protects investment in existing software

• Familiar API and development environment for new applications

• Enables unit testing on commodity hardware

A guest OS is larger and more complex than the MILS separation kernel. To manage schedule risk and reduce evaluation cost, partitions that include a guest OS should process a single level (e.g., secret vs. top-secret) of classified data. If a single CPU processes both secret and top-secret data, then one partition should contain the secret data and another partition should contain the top-secret data. Each partition is then “system high.” Evaluations of the secret and the top-secret partitions are independent because the high robustness MILS separation kernel can be trusted to keep them separate. A medium robustness evaluation for each application partition is appropriate. Medium robustness is approximately Common Criteria Evaluation and Assurance Level 4 (EAL4). Evaluation at this level is practical and achievable for large code bodies.

In the MILS architecture, a network protocol stack is middleware. Network protocol stacks often require their own execution context. Isolating network protocols into their own private partitions has several advantages: