An important reason to use virtualisation, especially in embedded technology, is to be able to run multiple programs in their own operating environment, securely separated from each other.
Applications you do not completely trust can first play in their own virtual sandbox. In theory, only the guest operating system inside the sandbox is vulnerable to attacks from the evil outside world.
In practice, it turns out that the underlying architecture of the hypervisor determines if the desired true separation can be achieved or not. The most common commercial hypervisors are based on a monolithic architecture (Figure 1).
There is just one hypervisor, which services all virtual sandboxes, each running a guest operating system. The hypervisor runs as part of the native monolithic operating system, side-by-side with the device drivers, file system and network stack, completely in kernel space.
This means the hypervisor is granted CPU privilege to access all system I/O resources and memory. From a security viewpoint this is not a good architecture. Just one vulnerability in the hypervisor itself could result in a hacker gaining access to the entire system, including all the guest operating systems.
The microkernel architecture, however, has been designed specifically to guarantee a robust separation of application partitions (Figure 2). This architecture puts the complex virtualisation program in user space.
In this model, every guest operating system uses its own instantiation of the virtualisation program, so we really have separate virtual boxes. An attack on the hypervisor of one of the guests can bring down one virtual box, but not the system or another virtual box. The kernel is the only component operating in kernel space.
Escape from the virtual box
Recently published papers have shown that the security of hypervisors can be undermined. In 2006, the Subvirt project demonstrated hypervisor rootkits undermining both VMware as well as VirtualPC. The Bluepill-project, led by the Polish security expert Joanna Rutkowska, went one step further and demonstrated a malware program that started to act as its own hypervisor under Windows. Tavis Ormandy, from Google, discovered weaknesses in QEmu, VMware, Bochs and a few lesser known hypervisor products, demonstrating it is possible to break out from the virtual box.
Protection Profile
So, for security-critical applications, you cannot simply rely on the claims of hypervisor and operating systems suppliers. For consumers, companies and governments to be able to compare the security of IT products they intend to buy, a number of national organisations have merged into an international organisation called Common Criteria for IT Security Evaluation, managed by the US National Information Assurance Partnership (NIAP).
Common Criteria has its corresponding evaluation and validation scheme (CCEVS) for a number of different product categories, including databases and smartcards. There is also a category for operating systems.
It is therefore advisable to first read the assessment report, as made by an independent Common Criteria Test Laboratory (CCTL), of the product you might consider using. Before you can start evaluating an IT product, you first have to describe what it should protect you against and under what conditions. This is a Protection Profile (PP) and often serves as an indication of the robustness you can expect from the product.
Making comparisons
Every IT product trying to meet a certain Protection Profile has an Evaluation Assurance Level (EAL). This number informs the buyer how sure they can be that the product provides the protection as described in the Protection Profile. EAL1 is the lowest level, and EAL7 the highest. The higher the level, the more test and evidence methods are required.
Obviously, a high robustness Protection Profile only makes sense if the IT product has been evaluated against a very high level of assurance (at least 6). Using these levels, a supplier’s claim about the security of its IT product can be evaluated by an independent, NIAP-accredited test laboratory. The resulting certificate, referring to the PP/EAL used, allows a proper apples-with-apples comparison of IT products.
CCEVS currently has a number of Protection Profiles for operating systems. The most common are the Controlled Access Protection Profile (CAPP) and the Separation Kernel Protection Profile (SKPP).
NIAP publishes a list on its website stating which operating systems have a certificate and which are still under evaluation.
The CAPP assumes the system is operational in a non-hostile environment and will protect you from inadvertent or casual attempts to breach the system security. However, it is acceptable to use a CAPP-based IT product in a bunker without a network connection.
The SKPP requires the operating system to contain security services and counter measures against attacks (or unauthorised access) through, for example, a network connection. SKPP also demands that the operating system supports strict and true separation of domains (including periods processing, no covert channels).
In addition, SKPP requirements include the use of formal methods to mathematically prove the security policies, formal specifications, formal correspondence between design and implementation, complete test coverage of all functional requirements and penetration testing by the US NSA, with complete access to the source code.
Author is Peter Hoogenboom, engineering manager at Green Hills Software