Project Topics
Get Complete Project Material File(s) Now! »
VMM Implementation Types
As a common usage, VMMs (also called hypervisors) are implemented with extra-features en-abling VM management (management console) and virtual hardware provisioning to VMs. In this state-of-the-art, we refer to a hypervisor as a VMM embedded with a management console, a memory manager, an input/output subsystem and a networking subsystem. We define a host system as the only set of OS and applications to have access to hardware resources not mitigated by the hypervisor. Conversely, guest VM alludes to the one with a restricted access to hardware resources. We distinguish two types of VMMs.
The type-I hypervisor alludes to a VMM directly operating the hardware resources. The host system runs alongside guest VMs, and both of them have to cope with the hypervisor. Their main difference at runtime is that the host system is permitted by hypervisor to access the hardware without restriction and have administrative privileges over the hypervisor while the guest VM are handled by virtual hardware environment. Thus, this approach corresponds to the classical VMM architecture. The Xen hypervisor [148, 12] and KVM [70] are two examples of type-I hypervisor implementations.
The type-II hypervisor runs as an application of the host system. It cannot directly access the hardware, but relies on the host OS routines to access hardware resources. Oracle Virtualbox [116] and QEMU [127] are two well-known type-II hypervisors.
Considered Threats and Attacks
In accordance with the methodology exposed in [149], we analyze the different attacks related to our reference architecture, according a set of six threats, namely spoofing, tampering, repu-diation, information disclosure, denial of service and elevation of privileges. In that context, we assume several hypotheses regarding the reference architecture and the attacker:
The instantiated virtual machine applications expose interfaces that are accessible remotely. The attacker is located remotely, and can use the legitimately exposed interfaces.
The hardware layer is not accessible to the attacker. We consider physical intrusion attacks out of the scope of system virtualization.
The assets targeted by the attacker are applications and data located in virtual machines. The objective of the attacker is to impact on the availability (denial of service), the integrity (alteration) or the confidentiality (retrieving) of an asset.
A component is considered as secured if not compromised, but may contain inherent soft-ware flaws known by the attacker. The attacker can exploit them to compromise a com-ponent, and gain influence over it.
We classify attacks with regard to threats, according to the notion of compromises: we consider a component as compromise, when the attacker is capable of executing an arbitrary code. We introduce a three-level classification based on the extension of [137]: compromise-free attacks (that are not related to compromises), compromising attacks (that enable compromises), and compromise-based attacks (that are based on compromises). Figure 2.7 provides an overview of this classification, while Table 2.2 details the relationships with the threats and the reference architecture.
Execution Environment of the Hypervisor
Compromising attacks may also include firmware exploitation attacks against the execution environment of the hypervisor. Hypervisors are running at the top of a hardware layer, except in the case of nested virtualization. They are therefore constrained by the hardware layer, which is composed of devices with their own firmwares. These firmwares may carry their own flaws, providing the necessary material to an attacker to compromise them. The corresponding threats are the hardware tampering, the information disclosure based on side channels, and the elevation of privileges to get control on the software components running over the hardware. For instance, such an attack is showcased in [163], in order to compromise the firmware of network interface card. These attacks are emphasized by the hard constraints regarding the upgrade procedure of these firmwares. Such upgrades are typically limited by the degradation of services during the upgrade process, or by the lack of support from manufacturers. These attacks are mainly based on the hardware oversight and hardware upgradability vulnerabilities.
Compromise-Based Attacks
The last category of attacks are compromise-based attacks. The two first categories (compromise-free and compromising attacks) are often the first steps towards establishing a more sophisticated attacks targeting a virtualization architecture. Consequently, we consider that compromise-based attacks require the prior compromise of a component to be performed. These attacks typically include the case of malicious virtual machines attacking the remainder of the virtualization architecture, and the case of a malicious hypervisor trying to snoop on the virtual machines it is in charge of.
Malicious Virtual Machines
The first category of attacks relies on malicious virtual machines. An hypervisor hosts several VMs, which share the same physical resources. They can be competing to access these resources. The hypervisor resource monopolization attacks consist in a malicious VM taking control on an hypervisor to gain an exclusive access to these resources. This leads to the violation of the hypervisor resource isolation. These attacks on physical CPU are described in [168]: a Xen scheduler vulnerability is used by a malicious virtual machine to steal compute cycles to other co-located machines. They typically exploit the co-residence and the virtualization method implementation vulnerabilities.
The VM hopping attacks consist in a malicious VM that directly targets another VM from the virtualization environment. The related threat concerns the VM applications, their runtime and utilities, and their OS kernel. They permit the tampering and the elevation of privilege in the virtualization architecture. These attacks can typically use common networking infrastructure and other resource sharing vulnerabilities to access the targeted VM. It can exploit software interfaces, configuration and hardware exposure vulnerabilities to perform a compromise.
The attacks regarding the VM monitoring from a VM consist in collecting information about a VM, without compromising it. They can typically rely on a passive monitoring of another virtual machine. The related threats are about VM applications, their runtime and their OS kernel, through the disclosure of information and the breaching of the non-repudiation principle. These attacks are mainly conditioned by the exploitation of side channels, and the co-residence of VMs. [14] illustrates the by-passing of an OS protection based on hypervisor side channels. The work in [165] makes use of co-residence and physical properties to affect memory pages owned by other VMs, to proceed to in-memory information leakage or even to build a hidden channel between both VMs. The co-residence issue is especially challenging in a public cloud infrastructure. The work in [132] details the steps to reach a VM co-residence with the targeted VM. Finally, authors of [167] explore how co-residence can contribute to cryptography key leaks based on CPU L1-cache. These attacks are based on the hardware physical properties, the virtualization method implementation and the inter-VM crosstalks vulnerabilities.
The VM escape to a VM attack aims at compromising the hypervisor, in order to access another VM. It is very similar to a VM hopping, and corresponds to the same threats, but relies on the hypervisor compromise to break the isolation. VM-hypervisor crosstalks vulnerabilities are typically involved in these attacks. The VM escape to an host relies on the hypervisor compromise from the malicious VM, in order to gain further control. In most of the cases, these attacks target legitimate interfaces between the hypervisor and the malicious VM, in order to compromise the hypervisor, such as the VENOM attack [48] and the Cloudburst attack [76]. These attacks take advantage of the VM-hypervisor crosstalks vulnerabilities.
Protection of the hypervisor
The hypervisor provides an execution environment to the VMs, enabling them to run in ac-cordance with the VMM properties [125]. In that context, [146] proposes the use of hardware to protect VMs from the host, by enforcing isolation through hardware resource access management and privacy based on a trusted platform module (TPM). However, this counter-measure supposes important prerequisites on the hardware architecture, which may not be considered in practice. Additionally, [79] introduces a method for filtering hypercalls and checking their integrity at the invokation. Virtual CPU context integrity checks as well as virtual memory encryptions are enforced during the execution of the hypervisor. In the area of OS-level virtualization, the Intel safeguard extension is used by SCONE [7] to protect containers against untrusted execution environments. This framework provides the necessary building blocks to design enclaved linux containers, that are resilient against tampering attacks from the OS, with a limited trust com-puting base (TCB). SCONE uses a limited pool of threads that are mapped with ones from the untrusted OS. The system calls are performed asynchronously with the assistance of a module outside the enclave. Complementary, the exploitation of command channels can be avoided by obfuscation methods, as detailed in [26]. [168] also describes a solution to CPU monopolization attacks, by switching virtual CPU scheduling to alternative methods (e.g. randomized scheduler, Bernouilli scheduler and uniform scheduler) to limit flaw exploitations.
The granularity of the hypervisor architecture also impacts on security. In order to avoid a monolithic architecture, [34] uses hypervisor virtualization features to decompose management OS capabilities across dedicated service VMs. These VMs are framed by coercitive security constraints, such as hypercall restrictions, security audits and frequent reboots. However, this approach only focuses on the management console segmentation, and does not address the in-ternal subsystems of the hypervisor. The NOVA [145] hypervisor goes further, by proposing a micro-hypervisor architecture. A minimum trusted computing base (TCB) resides on the host kernel (micro-hypervisor), while each virtual machine dedicated VMMs are executed in the user space, meaning host device drivers and remaining services. The lack of maturity of this approach introduces limitations regarding guest OS compatibities.
It is also important to cope with networking and storage security. In that context, the enforcement of access control security policies on VM resources is explored by the sHype hypervi-sor [138]. This solution, based on Xen, enables the enforcement of policies related to the manda-tory access control (MAC) on VM resource access, including network communications, standard I/O communications and shared memory. More precisely, the reference monitor enforces the policy on event channel operations, shared memory requesting and domain management oper-ations. The presented solution is limited to access control enforcement with the MAC model on a single hypervisor instance. TVDSEC [150] addresses the access control policy enforcement over several hypervisor instances. In return, only the enforcement over control flows is consid-ered. Networking may also serve for performing resource quarantines: the NICE framework [32] exploits a network controller to put in a quarantine state VMs that are potentially compromised.
Minimization of the attack surface
A second category of counter-measures concern the minimization of the attack surface, by ver-ifying the properties and restricting the capabilities of resources. In particular we focus on verification and capability dropping techniques.
Formal verification can be applied to both the OS kernel and the applications of virtual machines. It permits to assess the security properties of the components of the architecture, but also to verify the design of security mechanisms (e.g. cryptographic libraries). For instance, Klein et al. [71] introduces the design and the implementation of a micro-kernel, SEL4, featuring formal specifications. It relies on the Haskell purely functional programming language. The source code can be automatically translated into a formal specification that is then checked. The Hyperkernel [111] project proposes an OS kernel that can be assessed using the Z3 SMT prover. This OS makes use of the hardware-based virtualization feature to enforce an isolation between the kernel residing in root-mode and the process running in non-root mode. These approaches may imply an important cost for modifying/extending the code framed for formal specifications, and often suppose to define a modular architecture to prove the properties of components independently. Alternative approaches have also emerged to protect applications and guarantee security properties, without implying formal checking. Typically, virtual ghost [35] is a framework to protect user applications from an untrusted operating system. It enables the applications to control their own operating system-proof sandbox, and a layer interleaving the OS and the hardware is responsible for enforcing the sandbox isolation.
It is also possible to apply capability dropping techniques. Hardening methods are part of them and permit to reduce the attack surface of a system, by imposin a system to reduce its attack surface, by constraining parameter values and imposing (security) software compo-nents. Most applications come with their specific recommendations with respect to hardening. In addition to authorization restrictions and unnecessary software dropping, address space layout randomization enforcement is recommended. The images of resources can also be hardened in such a way that their applications are dedicated to a specific purpose, while considering their lifetime is restricted in accordance. A directory of unikernels is proposed in [89], facilitating the usage of constrained and ephemeral virtualized resources. The outsourcing of in-VM software management contributes also to this hardening. Most operating system images are provided with their software management tools. Therefore, the presence of those tools in the VM image can be questioned, as most Delegating the software management to the image manufac-turing process contributes to protect VM applications against related attacks and compromises.
Adaptation based on security programmability
Counter-measures are efficient at reducing the attack surface, but they have to constantly be adapted over time to cope with new threats and attacks. The programmability of resources and their security mechanisms contribute to this required adaptation. It can be driven by an orchestration activity relying on monitoring results.
The monitoring of resources can be performed based on introspection techniques. For instance, VMwatcher [64] permits to determine the internal state (memory and filesystem) of virtual machines. This enables to outsource some security mechanisms such as in-VM malware detection. Authors of [30] propose similar techniques, but applied from the guest OS during the execution phase. Active monitoring approaches, such as the LARES architecture [122], are also applied to observe virtual machines based on dedicated agents or probes. Detection approaches, such as the NICKLE framework [131], permit to identify and prevent rootkits. Finally, the hypervisor introspection is also applicable to VM virtual hardware environments, as developed by Slick [10] and TVDSEC [150]. The first one relies on a modification of the hypervisor (experimented in KVM) to track the activity of VMs on virtual storage, while the second one focuses on tracking VM networking flows. The monitoring may also consist in the identification of vulnerable configurations related to components of the virtualization architecture. For instance, the approach in [13] proposes a SAT solving method for supporting resource management. It permits to detect the presence of configuration vulnerabilities in preventive manner, considering the maintenance operations that are available.
The analysis of monitoring results can then drive orchestration activities in virtualization and cloud environments. An efficient and consistent orchestration is an important aspect to deploy and coordinate security mechanisms. Some efforts, such as [120], exploits orchestration languages to support access control policies in the area of virtualized network functions (VNF). The security policy mining contributes to the coherency of the orchestration by extracting high-level policy from entities enforcing low-level ones. Work in [55] applies this approach to extract network-wide access control policy from the configuration of multiple firewalls. Orchestration de-pends on the programmability of resources and their security mechanisms. To enforce security decisions taken by an orchestrator, the resources of the virtualization architecture can be dynam-ically reconfigured through programmability facilities. These reconfigurations enable to reduce the attack surface (e.g. setting up authentication) or to mitigate the attacks (e.g. isolating a compromised host through firewalling). Considered resources include the different components of the virtualization architecture, but also security mechanisms. We can distinguish different cases: (1) components supporting reconfigurations at runtime can be managed through their configuration interfaces, (2) statically-configured components that are restartable, can be modi-fied by changing the static configuration alteration and restarting the instance, (3) components that are non restartable (nor reconfigurable at runtime) can be addressed through dedicated methodologies, such as dynamic software updates developed in [156] using IncludeOS unikernels. We can also notice some recovery techniques, such as the TASER intrusion recovery system [50], capable of tracking the activity of a virtual machine, and recoverying its configuration to clean state after an attack.
Table of contents :
1 Introduction
1.1 Research Context
1.1.1 Involvement of Virtualization in Cloud Computing
1.1.2 Distribution of Resources over Cloud Environments
1.1.3 Exposure to Security Attacks
1.2 Problem Statement
1.3 Contributions
1.3.1 Analysis of Virtualization Models for Cloud Security
1.3.2 Software-Defined Security Architecture for Distributed Clouds
1.3.3 Generation of Protected Unikernel Resources
1.3.4 Extensions of a Cloud Orchestration Language
1.4 Outline of the Dissertation
2 System Virtualization: from Threats to Cloud Protection Opportunities
2.1 Introduction
2.2 System Virtualization Models
2.2.1 Context
2.2.2 System Virtualization
2.2.3 OS-Level Virtualization
2.2.4 Unikernel Virtualization
2.2.5 Synthesis
2.3 Security Analysis based on the Reference Architecture
2.3.1 Identification of Vulnerabilities
2.3.2 Considered Threats and Attacks
2.3.3 Compromise-Free Attacks
2.3.4 Compromising Attacks
2.3.5 Compromise-Based Attacks
2.4 Counter-Measures
2.4.1 Integration of security mechanisms at design time
2.4.2 Minimization of the attack surface
2.4.3 Adaptation based on security programmability
2.5 Conclusions
3 SDSec Architecture for Distributed Clouds
3.1 Introduction
3.2 Related Work
3.3 Software-Defined Security Overview
3.3.1 Objectives
3.3.2 Design principles
3.4 Software-Defined Security Architecture
3.4.1 Security Orchestrator
3.4.2 Policy Decision Points
3.4.3 Policy Enforcement Points
3.4.4 Interactions Amongst Components
3.5 Architecture Evaluation
3.5.1 Validation Scenarios
3.5.2 Practical Considerations
3.6 Summary
4 On-the-Fly Protected Unikernel Generation
4.1 Introduction
4.2 Related Work
4.3 Background on Unikernels
4.4 Software-defined Security Framework Based on Unikernels
4.4.1 On-the-fly Unikernel Generation
4.4.2 Benefits of Unikernels for Software-defined Security
4.4.3 Reactivity Improvement through Image Pooling
4.4.4 Integration with the SDSec Architecture for Distributed Clouds
4.5 Performance Evaluation
4.5.1 Prototype Implementation
4.5.2 Qualitative and Quantitative Evaluations
4.6 Summary
5 Topology and Orchestration Specification for SDSec
5.1 Introduction
5.2 Related Work
5.3 TOSCA-Oriented Software-defined Security Approach
5.4 Extensions of the TOSCA Language
5.4.1 The TOSCA Language
5.4.2 Describing Unikernels
5.4.3 Specifying Security Requirements
5.4.4 An Illustrative Case
5.5 Underlying Security Framework
5.5.1 Main Components
5.5.2 Interpreting SecTOSCA Specifications
5.5.3 Building and Orchestrating Unikernel Resources
5.5.4 Adapting to Contextual Changes
5.6 Summary
6 Prototyping and Evaluation
6.1 Introduction
6.2 Implementation Prototypes
6.2.1 Young Unikernel Generator
6.2.2 Moon Framework
6.2.3 HTTP Authentication and Authorization for MirageOS Unikernels
6.2.4 Application Firewalling for Mirage OS Unikernels
6.3 Evaluation Scenarios
6.3.1 Experimental testbed
6.3.2 Performance of the three approaches
6.3.3 Performance with a pool of protected unikernels
6.3.4 Security policy propagation and enforcement
6.4 Summary
7 Conclusions
7.1 Summary of Contributions
7.1.1 Analyzing Virtualization Models for Cloud Security
7.1.2 Designing a Software-defined Security Architecture
7.1.3 Generating Protected Unikernel Resources on The Fly
7.1.4 Extending the TOSCA Cloud Orchestration Language
7.1.5 Prototyping and Evaluating the Solution
7.2 Discussions
7.3 Research Perspectives
7.3.1 Exploiting Infrastructure-As-Code for Security Programmability
7.3.2 Supporting the Security of IoT Devices
7.3.3 Checking the Consistency of Security Policies
7.3.4 Contributing to Cloud Resilience
7.4 List of Publications
8 Appendix
8.1 Linux Features for OS-level Virtualization Support
8.2 Glibc System Calls Invokation Implementation
9 Résumé détaillé en français du mémoire
9.1 Introduction
9.1.1 Contexte des travaux
9.1.2 Identification des problématiques
9.1.3 Approche proposée
9.2 Contributions
9.2.1 État de l’art des modèles de virtualisation pour le cloud et analyse de leur sécurité
9.2.2 Architecture pour la programmabilité de la sécurité dans le cloud distribué
9.2.3 Génération à la volée d’images unikernels protégées
9.2.4 Spécification de l’orchestration pour la programmabilité de la sécurité
9.3 Conclusion
9.3.1 Analyse critique
9.3.2 Perspectives de recherche
Bibliography
