Deploying Virtual Machines on Shared Platforms

In this report, we describe mechanisms for secure deployment of virtual machines on shared platforms looking into a telecommunication cloud use case, which is also presented in this report. The architecture we present focuses on the security requirements of the major stakeholders’ part of the scenario we present. This report comprehensively covers all major security aspects including different security mechanisms and protocols, leveraging existing standards and state-of-the art wherever applicable. In particular, our architecture uses TCG technologies for trust establishment in the deployment of operator virtual machines on shared resource platforms. We also propose a novel procedure for securely launching and cryptographically binding a virtual machine to a target platform thereby protecting the operator virtual machine and its related credentials

A methodology for testing virtualisation security

There is a growing interest in virtualisation due to its central role in cloud computing, virtual desktop environments and Green IT. Data centres and cloud computing utilise this technology to run multiple operating systems on one physical server, thus reducing hardware costs. However, vulnerabilities in the hypervisor layer have an impact on any virtual machines running on top, making security an important part of virtualisation. In this paper, we evaluate the security of virtualisation, including detection and escaping the environment. We present a methodology to investigate if a virtual machine can be detected and further compromised, based upon previous research. Finally, this methodology is used to evaluate the security of virtual machines. The methods used to evaluate the security include analysis of known vulnerabilities and fuzzing to test the virtual device drivers on three different platforms: VirtualBox, Hyper-V and VMware ESXI. Our results demonstrate that the attack surface of virtualisation is more prone to vulnerabilities than the hypervisor. Comparing our results with previous studies, each platform withstood IOCTL and random fuzzing, demonstrating that the platforms are more robust and secure than previously found. By building on existing research, the results show that security in the hypervisor has been improved. However, using the proposed methodology in this paper it has been shown that an attacker can easily determine that the machine is a virtual machine, which could be used for further exploitation. Finally, our proposed methodology can be utilised to effectively test the security of a virtualised environment

Security Aware Virtual Machine Allocation Policy to Improve QoS

Cloud service providers find managing the energy consumption for datacentres as a critical operation. Significant energy is being used by a rising spike in the number of data centres. To overcome this challenge datacentres, attempt to reduce the number of active physical servers by carrying out virtual machine consolidation process. However, due to inadequate security measures to verify hostile cloud users, the security threats on cloud multitenancy platform have escalated.  In this paper we propose energy efficient virtual machine consolidation using priority-based security aware virtual machine allocation policy to improve datacentre security. The proposed security solution considers the host threat score before virtual machine placement, which has reduced the security threats for co-residency attacks without impacting datacentre energy consumption

Using a virtual machine to protect sensitive Grid resources

Most Grid systems rely on their operating systems (OSs) to protect their sensitive files and networks. Unfortunately, modern OSs are very complex and it is difficult to completely avoid intrusions. Once intruders compromise the OS and gain system privilege, they can easily disable or bypass the OS security protections. This paper proposes a secure virtual Grid system, SVGrid, to protect sensitive system resources. SVGrid works by isolating Grid applications in Grid virtual machines. The Grid virtual machines' filesystem and network services are moved into a dedicated monitor virtual machine. All file and network accesses are forced to go through this monitor virtual machine, where SVGrid checks request parameters and only accepts the requests that comply with security rules. Because SVGrid enforces security policy in the isolated monitor virtual machine, it can continue to protect sensitive files and networks even if a Grid virtual machine is compromised. We tested SVGrid against attacks on Grid virtual machines. SVGrid was able to prevent all of them from accessing files and networks maliciously. We also evaluated the performance of SVGrid and found that performance cost was reasonable considering the security benefits of SVGrid. Furthermore, the experimental results show that the virtual remote procedure call mechanism proposed in this paper significantly improves system performance. Copyright © 2006 John Wiley & Sons, Ltd.Peer Reviewedhttp://deepblue.lib.umich.edu/bitstream/2027.42/56163/1/1134_ftp.pd

A Generic Checkpoint-Restart Mechanism for Virtual Machines

It is common today to deploy complex software inside a virtual machine (VM). Snapshots provide rapid deployment, migration between hosts, dependability (fault tolerance), and security (insulating a guest VM from the host). Yet, for each virtual machine, the code for snapshots is laboriously developed on a per-VM basis. This work demonstrates a generic checkpoint-restart mechanism for virtual machines. The mechanism is based on a plugin on top of an unmodified user-space checkpoint-restart package, DMTCP. Checkpoint-restart is demonstrated for three virtual machines: Lguest, user-space QEMU, and KVM/QEMU. The plugins for Lguest and KVM/QEMU require just 200 lines of code. The Lguest kernel driver API is augmented by 40 lines of code. DMTCP checkpoints user-space QEMU without any new code. KVM/QEMU, user-space QEMU, and DMTCP need no modification. The design benefits from other DMTCP features and plugins. Experiments demonstrate checkpoint and restart in 0.2 seconds using forked checkpointing, mmap-based fast-restart, and incremental Btrfs-based snapshots