In Part 1 of this two-part story, we reviewed multiple independent levels of security (MILS) architecture, which provides an effective approach to creating and validating an operating system for multi-level secure systems. In Part 2, we discuss how MILS can be used to host applications.
Multiple independent levels of security (MILS) architecture was originated to permit the efficient development and certification of multi-level secure systems. The MILS approach allows the scrutiny of code using a four-layer approach consisting of trusted hardware, separation kernel, middleware, and applications. The separation kernel is built on four fundamental security policies: information flow, data isolation, periods processing, and fault isolation.
The implementation of these four fundamental security policies provides a secure foundation for the development of multi-level secure systems and cross domain solutions (CDSs). This enables the VxWorks MILS 2.0 separation kernel to host applications of different domains (e.g., security classifications, or coalition partners) concurrently on the same processor, using a variety of guest operating system environments.
Secure application development
The high assurance environment (HAE) provides a single-threaded, minimal runtime environment, using a small code footprint. This enables the cost-effective development of high EAL/high robustness applications that require a high degree of scrutiny, such as a cross-domain guard performing a write-down of data from Top Secret to Secret. The HAE can also be used in conjunction with medium robustness guest OS environments to partition new or existing applications into security-critical and non-critical components; this divide-and-conquer approach means that application components need only be evaluated to the appropriate level of assurance, rather than performing a costly evaluation of all application functionality to the level of the most security-critical component.
The VxWorks Guest OS, a descendent of VxWorks 5.5, provides a multi-threaded environment, which is designed to support medium assurance applications at EAL4+, but also medium-assurance components of high-assurance systems, using the divide-and-conquer approach discussed previously. The VxWorks environment provides familiar functionality and API, which enables existing, federated VxWorks-based applications to be easily migrated to the VxWorks MILS architecture, as well as the development of complex new applications. VxWorks Guest OS also supports the general network stack which is an IPv4-based network stack providing basic UDP and TCP networking capabilities.
The Linux Guest OS provides a Wind River Linux 3.0.2 environment on top of the MILS separation kernel, and is also designed to support medium assurance applications at EAL4+. This enables existing Linux and POSIX-based applications to be migrated to the VxWorks MILS platform, enabling reuse of existing intellectual property for advanced networking and routing applications.
The high-assurance network stack (HANS) implements an IPv4-based UDP and TCP networking stack using separate partitions to enable multi-single level secure (MSLS) network communications. Using this architecture, multiple levels of data can be carried on the network, but are always separated.
In this networking architecture, a high assurance (HA) partition is used to ensure that the packets destined for different partitions are kept separate within the MILS system’s partitions (see figure 4). On ingress, the HA partition uses a discriminator (e.g., a VLAN Tag per IEEE 802.1Q) to determine the destination partition and subsequently forward the data packet to that partition.1
On egress, the HA partition verifies that the appropriate discriminator has been applied to the Ethernet frame based on the partition sourcing the frame. This networking architecture thus places the network protocols in a low- or medium-assurance partition, while encapsulating the discriminator verification in the HA partition. The MSLS security requirements for this network architecture are focused on the HA partition. The separation kernel enforces both the separation of the partitions as well as the communication (information flow) between the partitions.
Figure 1: In a notional high-assurance network stack (HANS), a separation kernel maintains separation between UDP and TCP packets destined for different partitions. (Courtesy of Wind River Systems)
The components discussed above can be combined to develop sophisticated CDS and MLS systems, for example a notional MILS-based gateway (see figure 2). This system is connected to two networks of different security classifications, filtering and routing data between them. It uses a separate partition for each network interface, containing a network stack and device driver running in user mode (boxes labeled “Net”). This is achieved by the separation kernel mapping an Ethernet device into the appropriate partition, which then performs direct access via polled-mode I/O; this means that there is no undesirable device-driver code running in the separation kernel and there is no possibility of network traffic causing partition jitter through interrupts (which could be used as a covert timing channel). The system also has dedicated guards which filter the traffic in each direction, and communication between partitions is implemented using secure IPC (SIPC).
Figure 2: For each network interface, a notional MILS-based gateway uses a separate partition that contains a network stack and device driver running in user mode (boxes labeled “Net”). The separation kernel maps an Ethernet device into the appropriate partition, which then performs direct access via polled-mode I/O. Dedicated guards filter the traffic in each direction, and communication between partitions is implemented using a secure IPC (SIPC) approach (actual SIPC paths through the SK are not shown). (Courtesy of Wind River Systems)