Adding real-time Java to a MILS operating system

Story

September 04, 2012

Usually, a Multiple Independent Levels of Security (MILS) operating system is a special configuration of a more general real-time operating system that is designed to simplify the development of software systems supporting multiple independent levels of security. Such systems are especially common in military scenarios where, for example, the same computer system may need to isolate top-secret data belonging to one national government from classified data belonging to a coalition of governments such as NATO (Figure 1).

 

Figure 1: Secure MILS operating system configured to restrict information flow between partitions

(Click graphic to zoom by 1.9x)

 

Conceptually, a MILS operating system maintains logical partitions to isolate the memory, CPU time, and other resources accessible to a particular application and to limit the interaction between applications running in different logical partitions. Configuration of the MILS operating system for a particular set of applications allows developers to establish the rules that govern interaction between partitions. A rule might state, for example, that partition A is only allowed to pass messages to partitions C and D.

The ideal of MILS partitioning is to reduce the costs of the security audit that is required to prove that the system is sufficiently secure. The operating system’s implementation of partitioning is certified to be secure by the operating system vendor and the costs of this certification are shared between all licensees. Given that the operating system can guarantee the absence of communication between applications running in different partitions, much less effort is required to understand and document the security-sensitive behaviors of each application. Adding a Java Virtual Machine (VM) to a MILS operating system greatly simplifies the porting and development of application software to MILS environments.

Case study: Pragmatics of deploying software within MILS environments

To facilitate the security audits that assure the absence of communication between independent partitions, the companies that develop MILS operating systems generally restrict the set of services provided by the operating system to applications running within MILS partitions. Each MILS environment presents different challenges with regard to effective execution of a Java virtual machine. Let’s look at some of the problems encountered when a real-time virtual machine product was ported to a particular Commercial Off-the-Shelf (COTS) MILS operating system at the request of a customer in the military and aerospace industry.

Among the limitations encountered in this MILS operating system, some of the constraints that were enforced by this MILS operating system in order to assure system security included the following:

1. It was not possible to write to a program’s text segment.
2. The system provided no command-line facility for setting environment variables.
3. The system did not support dynamic linking of native libraries.
4. Though not a general limitation of this COTS MILS operating system, the platform targeted by our customer lacked a file system.

Given these restrictions, which are typical of deeply embedded MILS deployments, it is clear that considerable porting and integration effort would be required before most off-the-shelf applications would run in this environment. The portability of Java offers the potential of significantly reducing the costs of doing this porting and integration work.

The relevance of Java to MILS applications

Java is especially relevant to the development of secure software because the language is more strongly typed than C and C++. Since early development of the Java language focused on Internet applications, security has been paramount in its design. Java, for example, forbids coercions between pointer and non-pointer data types, and it forbids pointer arithmetic. Furthermore, every access to a Java array performs an array bounds check. An exception is thrown instead of allowing software applications to reach beyond the end of an array’s valid data. Likewise, the Java runtime environment checks for stack overflow and throws an exception instead of allowing a thread to trample on memory beyond the end of the thread’s allocated stack. In general, these security features that are built into the Java language completely eliminate the large majority of vulnerabilities typically exploited in the implementations of Trojan horse and virus software that commonly infect C and C++ applications.

A strength of Java that is especially relevant to the challenge of implementing new software capabilities within a MILS environment is that, compared to more traditional languages, Java significantly reduces the effort required to implement, port, and integrate independently developed software components into working applications. Representative projects find developers are typically twice as productive during the development of new functionality and up to 10 times more productive reusing software components when working in Java rather than C or C++. This is because the Java language supports higher-level abstractions, is more portable, and encourages tighter encapsulation than C and C++. The value of these benefits is highlighted in experience reports as summarized in Figure 2.

 

Figure 2: Relevance of Java to development of special-purpose, secure dedicated systems

(Click graphic to zoom by 1.9x)

 

Built-in tracing garbage collection, which automatically reclaims the memory of dynamically allocated objects that are no longer relevant to the application, is one Java feature that makes it especially easy to integrate independently developed COTS Java components into a MILS application. Whenever an object is allocated by one component and used by other components, a C or C++ engineer is required to design and implement a protocol for detecting the end of the object’s useful lifetime and reclaiming its memory at that time. With Java, dead objects are detected and reclaimed automatically, and reclaimed memory is automatically defragmented as a valuable side effect of most automatic garbage-collection techniques. Besides reducing the intellectual effort required to develop and integrate software components, this feature eliminates the need to debug many common memory management programming errors related to dangling pointers, memory leaks, and memory fragmentation.

Thus, being able to implement MILS applications in the Java language is highly desirable. The language is more secure than traditional legacy languages like C and C++, it reduces the effort required to implement custom-tailored functionality, and it delivers tremendous cost savings during reuse and integration of independently developed software components.

Porting a Java VM to a COTS MILS environment

To deploy Java software within a MILS partition, it is first necessary to install a Java virtual machine runtime environment within the MILS partition. The Java virtual machine provides the standard Java libraries, a Java class loader, the Java byte-code interpreter and/or a Just-In-Time (JIT) compiler, and an implementation of a tracing garbage collector. With the Java virtual machine in place, all the traditional benefits of programming in Java are readily available.

Given that a MILS environment typically offers far fewer services than the comparable non-MILS configuration of the same operating system, virtual machine products that have been configured to run on traditional or real-time operating systems will probably not run within a MILS partition. Recently, a customer requested that we provide virtual machine support for a particular COTS MILS operating system environment.

Because of the MILS-imposed limitations of this MILS environment, there were a few Java features that could not be supported. But for the most part, the MILS configuration of the virtual machine technology described supports all of standard-edition Java. The following five sections constitute a case study of the Java configuration’s rationale and available workarounds.

#1 – High Assurance Network Stack (HANS)

Consistent with its objectives to support improved security, the customer-selected MILS operating system was distributed with an option to use a high-assurance network stack. This network stack ran in an isolated MILS partition, allowing it to run at very high priority without compromising the fair share of CPU time that is budgeted for other MILS partitions. Having the network stack in its own small partition allowed the stack to be isolated from errors in individual applications. An application in a different partition could crash and restart without compromising the integrity of the HANS. Further, the CPU time and memory resources consumed by the HANS were limited by the constraints of the partition it ran in. This provided certain protections against denial of service attacks on the network stack implementation.

Given that the amount of memory and CPU time dedicated to HANS implementation was restricted by the MILS operating system, only the HANS partition itself is compromised by another computer’s network communication requests to interact with this computer at higher rates than it is prepared to handle. While the HANS might drop packets in this scenario, applications running in other MILS partitions would not be compromised by the denial of service attack.

The virtual machine integration with this MILS environment supported the use of HANS, which accommodated a small number of differences between the HANS and the standard network stack APIs. In particular, the HANS did not enumerate the network devices configured for a particular MILS virtual board configuration. Instead, a command-line option allowed system integrators to supply the list of configured network devices. Domain name service functions gethostname() and also hostGetByName() were also not supported by HANS. The Atego Perc Ultra virtual machine technology’s MILS integration provided the customer with an opportunity to implement these services using proprietary table-based lookups for these services if necessary.

#2 – No debugging of compiled code

Since the MILS environment forbade writing to the text segment, it was not possible to set breakpoints in Java code that was statically compiled and linked into the runtime image.

However, several approaches could be used by Java developers who need debugging capabilities. First, because Java is such a portable programming language, it is usually possible to fully debug an application on a more full-featured platform, and then deploy the debugged application on the MILS platform. Second, if debugging is absolutely essential within the MILS environment, it is still possible to debug Java applications that are running as interpreted byte code.

#3 – No dynamic loading of native libraries

Many Java applications comprise a combination of Java and native code, often written in C or C++. When native components are part of a Java application, it is most common to load the native code dynamically under the direction of the Java System.loadLibrary service. This service was not available in the MILS integration of the real-time virtual machine. Instead, system integrators have the option to statically link native libraries.

#4 – Specialized virtual file system

To support MILS platforms that lack file system support, we implemented a virtual file system as part of the MILS port. This virtual file system allowed Java applications to create, write, and read file data stored in memory. Availability of the virtual file system made it much easier to test the virtual machine implementation and to port off-the-shelf Java code onto MILS platforms that are otherwise missing file support.

#5 – No environment variables

Environment variables are often used to hold key configuration data as a convenience to users. Configuration options specified by environment variables need not be repeated on command lines each time an application is started. Since the MILS environment did not provide users with an ability to set environment variables, this convenience was not generally available. Instead, MILS Java applications generally receive configuration data as command-line arguments.

Java reduces costs, adds reliability to MILS software systems

Enabling Java development within a MILS operating system partition makes perfect sense. Virtual machine technologies such as the Atego Perc Ultra described make it possible to run standard-edition Java on MILS, providing cost savings and reliability benefits to projects that exploit Multiple Independent Levels of Security.

Dr. Kelvin Nilsen, Chief Technology Officer Java, Atego Systems, oversees development of Perc virtual machine technologies. He participates in the Java Community Process as a member of the JSR 282 and JSR 302 expert groups. He holds a B.S. in Physics from Brigham Young University, and M.S. and Ph.D. degrees in Computer Science from the University of Arizona. He can be contacted at [email protected].

Atego Systems 858-356-5446 www.atego.com