Compute and hypervisor security¶

In this context we see two types of threats:

• hypervisor threats
• multi-project threats

Malicious application can escape the VM through exploitation of a vulnerability or a direct access to hardware or hypervisor OS and compromise other VMs running on a physical node which may belong to another projects (EoP).

The hypervisor security should be a prime concern because a single fault on the hypervisor level may compromise the whole environment.

For example, having access to the hypervisor an attacker can look into VM images by simply mounting a virtual disk (information disclosure). Even more, mounting a filesystem as read only can help to avoid tampering. An attacker becomes untraceable because peeking files this way does not update file access time (repudiation).

To mitigate EoP on a hypervisor:

• Use the hypervisor certified against FIPS 140-2 and take Common Criteria Certification requirements into consideration.
• Limit access to hypervisor OS (a full OS or kernel the hypervisor runs on), the VM manager, and all interfaces used to manage VMs.
• Do not use hypervisor memory optimization such as Copy-on-Write (COW) mechanisms shown to be vulnerable to side-channel attacks when used in multi-project environment.
• Disable PCI passthrough for your hypervisor, which means that an VM instance should not have a direct access to hardware such as memory (DMA) or video cards (GPUs).
• Harden virtual hardware (QEMU for KVM) by:
  • Minimizing the code base by removing unused components from a QEMU configuration.
  • Building QEMU with compiler hardening enabled, which may include: stack protection, data execution prevention, Address Space Layout Randomization (ASLR) by enabling Position Independent Executable (PIE)
  • Using mandatory access controls such as sVirt, SELinux, AppArmor, or grsecurity to put QEMU process into a separate security context.
• A hypervisor must host only VMs of the same security level that can be classified based on their role, function, or access to sensitive data. Use Host Aggregates and Availability Zones to group Compute nodes for running VMs of the same security level.

To mitigate EoP on for a Compute service:

• Limit an access by providing strict access permissions to the nova.conf file and /var/lib/nova folder.
• Use file integrity monitoring (FIM) tools such as iNotify or Samhain to trace unexpected files modifications.
• Use rootwrap to execute Compute commands as the root user.
• Use trusted compute pools.
• Implement centralized logging to mitigate a risk of a repudiation attack.
• Enable mandatory access control (MAC) with SELinux, AppArmor, or grsecurity.
• Enable encryption for Compute metadata traffic.