Secure virtualization for tactical environments
StoryApril 19, 2012
David Egts
Red Hat
Virtualization has proven its value in the data center, but can it work in tactical environments? Yes, but only if it?s secure.
The evolution of computing capabilities to allow the mobilization of data has paved the way for the transformation of tactical vehicles into rolling data centers. These impressive machines have provided invaluable resources for warfighters to dominate the battlefield. Unfortunately, despite the obvious benefits to packing a Humvee or tank with real-time intelligence computing equipment, these capabilities come at a not-so-obvious price: a sacrifice of precious power, cooling capabilities, and logistical space to accommodate the new equipment. For example, too many computers could adversely impact visibility or generate additional heat in an already scorching environment, dulling a soldiers’ reaction time and potentially increasing health and safety risks.
Interestingly, these rolling data centers are experiencing many of the same challenges found in today’s enterprise data centers – again, power drain, insufficient cooling, and lack of space. To address these challenges, data center managers have turned to virtualization to perform physical to virtual server consolidation, regularly achieving a 10 to 1 optimization or better. Can the lessons learned by virtualization in the data center also benefit tactical vehicle environments? What about special security requirements of tactical vehicles that contain content of differing classification levels? It is essential to understand the unique challenges and similarities between virtualized and physical server consolidation, as well as some of the secure virtualization advances made by the open source community that can be directly applied to help the warfighter.
Benefits of virtualization
There are several benefits to the deployment of virtualization to the field and in data centers, including consolidation, uniformity, live migration, and performance, which can specifically aid warfighters and increase efficiency on the front lines.
Consolidation
When workloads are consolidated with virtualization, hardware utilization increases. More can be done with less hardware, resulting in power, space, and cooling savings. In tactical environments, capabilities can be added with nominal increases in compute requirements. By consolidating workloads on fewer physical systems, the newly available space can be repurposed for additional mission features, more bullets, and literally more elbow room for the crew.
Uniformity
Virtualization allows data center managers to abstract hardware from the OS. This allows the data center manager to acquire the best performing hardware, for the lowest possible price, without needing to recertify software stacks. Hardware vendors can be pitted against one another to deliver the best value. In tactical environments, this advantage is even more profound, with no need for each application to have its own computer with an exotic form factor, power requirements, proprietary connectors, and so on. As a result, new capabilities can be added much more easily and hardware refreshes can happen much more quickly because, as mentioned, recertification time is reduced. Additionally, not every vehicle may need the same capability, so the need to rigidly budget power, space, and cooling, whether the capability is used or not, becomes relaxed. In the end, uniformity makes the warfighter much more nimble.
Live migration
If imminent hardware failure is detected on a hypervisor in the data center, a workload can be live migrated with zero downtime. Even if the hypervisor fails unexpectedly, the virtual machines running on it can be restarted on other hardware without user intervention. In tactical environments, battle damage resulting in the loss of a computer may result in loss of critical capabilities needed in the heat of battle. By running workloads directly on physical hardware, the capability may not be restored until the warfighter returns for the vehicle to be serviced, which may be too late. If the workload is virtualized, it could be migrated in real-time to or restarted on a functional server elsewhere in the vehicle without warfighter intervention. As a result, the probability of the warfighter losing a mission-critical component during battle for an extended period of time is lessened.
Performance
Some workloads that require low-latency or high-bandwidth communication between systems actually run faster when virtualized on the same piece of hardware. This is because the virtual network communication is done over the system backplane instead of going from physical system to physical system across a much slower and higher latency networking infrastructure. This increased performance and lower latency can help the warfighter respond much more quickly in the heat of battle.
Is virtualization secure?
Not by itself. If a hypervisor is compromised, not only is it compromised, but so are the virtual machines running on it as well as the virtual machine disk files connected to the hypervisor that may be running on it, on another hypervisor, or at rest. When a hypervisor exploit happens, restoring all virtual disk files from a known reliable backup is needed. If the time of exploit cannot be pinpointed, a full reinstall from scratch may be necessary. Many virtualization security solutions put in place offer a trusted means for the virtual machines to communicate with each other, but these tools offer no protection in the event of a hypervisor compromise. If virtualization is to be deployed in tactical environments, the hypervisors must be secure so the warfighter can trust the integrity of the components supporting the mission. So do technologies exist to prevent this type of exploit? Yes, thanks to the open source community.
Secure virtualization with sVirt: sVirt is a secure virtualization open source project, built upon a time-tested SELinux open source project pioneered by the NSA and the commercial software industry, dating back to 1999. sVirt is used to securely isolate KVMs (or Kernel-based Virtual Machines) from the hypervisor and from each other. Before we get into the details of sVirt, let’s do a quick review of SELinux and KVM:
SELinux predates x86-based virtualization and was originally used to lock down physical systems to prevent rogue applications from harming one another as well as the main system. SELinux is all about labeling. Every object on an SELinux system is labeled according to its function. This includes processes, users, files, hardware devices, network ports and adapters, and so on. The SELinux policy allows objects with certain labels to explicitly access objects with other labels and deny everything else. For instance, if a rogue web server process wants to read a password file, SELinux will block and log the access since the SELinux policy does not explicitly allow processes with a web server label to access files labeled as password files. SELinux is not an add-on to Linux – it is built in. SELinux has been enabled by default in mainstream enterprise Linux distributions since 2007.
KVM is an open source project that emerged in 2006 and was accepted in the upstream Linux kernel in 2007 and can today be found in numerous Linux distributions. KVM is unique in that all KVM virtual machines are Linux processes. As such, KVM is very lean because it can leverage the time-tested Linux operating system to manage VMs, perform hardware enablement, and leverage advances in power efficiency and performance, to name a few. As a tremendous side effect, in the same way a web server process can be confined with SELinux policy, a KVM virtual machine process with the SELinux policy called sVirt, mentioned previously, can also be confined.
At a high level, sVirt works by placing SELinux “force fields” around virtual machines, which confine what they can do. sVirt can even protect virtual machine guests that do not have the built-in protections of SELinux like Windows, as pictured in Figure 1.
Figure 1: High-level overview of KVM with sVirt protection
(Click graphic to zoom by 1.9x)
|
|
When a virtual guest starts, the KVM Linux process is given a unique SELinux label by sVirt. Correspondingly, the virtual disk file of that virtual machine is given a matching label. With the exception of the process and the virtual disk file, no other object on the system has the same label. When a second virtual machine starts, the second virtual machine’s KVM Linux process and virtual disk file are given their own unique but matching labels. This is all pictured in Figure 2.
Figure 2: Unique virtual machine process and disk file dynamic labeling by sVirt
(Click graphic to zoom)
|
|
In the event that a virtual machine is able to do a hypervisor exploit and gain administrator access, sVirt at the kernel level confines the virtual machine to only what is allowed by the sVirt SELinux policy, namely to see its own disk file (not others), use other resources narrowly allowed by virtual machines, and nothing else.
Sounds great, but does sVirt really work? Actually, yes. At the Black Hat USA 2011 conference, Nelson Elhage presented a method to compromise KVM, but the use of sVirt defeated his approach.
Side note: Interestingly enough, the labels created by sVirt are Multi Category Security (MCS) labels. MCS (and Multi Level Security or MLS) labels are concepts derived directly from secure computing efforts driven by the NSA and other agencies. The fascinating part is that this demonstrates how agencies with classified data requirements have helped the open source community take their requirements from niche to mainstream. By leveraging the proven MCS capabilities of SELinux, Common Criteria certification of KVM with sVirt becomes much easier.
Red Hat is a contributor on both the sVirt and KVM projects, as well as SELinux, utilizing their Red Hat Enterprise Linux and Red Hat Enterprise Virtualization products. For more information on these projects, visit www.selinuxproject.org or www.linux-kvm.org.
Future work
Things can always be made better and more secure. An additional concept being integrated into virtualization is the concept of resource control groups or cgroups. In the same way as SELinux can confine access by Linux processes, cgroups is used to control the CPU, network, memory, and other resources consumed by Linux processes. Since KVM virtual machines are Linux processes, they can also be confined by cgroups in the same way they are confined by sVirt. This paves the way for resource fairness when it comes to virtualization multitenancy. One integrator’s virtual machine won’t overconsume their fair share of system resources, which could adversely affect another integrator’s virtual machine on the same hypervisor. From a security perspective, cgroups can also be used to prevent a denial of service attack on one virtual machine from taking down an entire hypervisor.
Another open source effort under consideration is that of trusted computing. As computing resources containing sensitive data are pushed deeper and deeper into the battlefield, a secure means to boot and trust federated systems that aren’t locked and under guard in a data center becomes paramount. The open source community along with government agencies and hardware and software vendors are actively working on trusted computing technologies to address these needs. Since KVMs are Linux processes, the ability to rapidly adopt these emerging trusted computing methodologies becomes much more straightforward as opposed to inventing something wholly new.
David Egts is a Principal Architect at Red Hat, Inc., specializing in the application of open source enterprise infrastructure technologies within federal, state, and local government agencies, the Department of Defense, and educational institutions. Contact Dave at [email protected].
Red Hat 703-748-2201 www.redhat.com
