Secure Out-of-band Remote Management of Virtual Machines
Enhance the security of virtualized systems by enabling out-of-band remote management through virtual devices, mitigating risks of information leakage and insider threats. Explore the challenges and previous approaches to secure remote management in cloud environments.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
Secure Out-of-band Remote Management of Virtual Machines with Transparent Passthrough Shota Futagami, Tomoya Unoki, and Kenichi Kourai Kyushu Institute of Technology, Japan
2 Remote Management of VMs IaaS clouds Run virtualized systems and provide virtual machines (VMs) Out-of-band remote management Enable users to manage VMs via virtual devices E.g., virtual serial devices, keyboards, and video cards Even on network configuration errors and at boot time virtualized system I/O virtual devices user VM user cloud
3 Information Leakage by Insiders Virtual devices may be managed by untrusted cloud operators 28% of cybercrimes are caused by insiders [PwC'14] 35% of admins have accessed sensitive information [CyberArk'09] Cloud operators can easily eavesdrop on and tamper with I/O of out-of-band remote management virtualized system operators user VM password virtual devices user
4 Previous Approaches Several systems trusting the hypervisor have been proposed Encrypt I/O between users and the hypervisor [Egawa+ CloudCom'12] Virtual devices handle only encrypted data Encrypt I/O in users' special VMs [Butt+ CCS'12] These VMs are protected by the trusted hypervisor virtualized system operators encrypted data virtual devices user VM ? remote client trusted hypervisor
5 Issues (1/2) The hypervisor can be compromised by insiders Cloud operators can abuse rich interfaces to privileged components Not all the hypervisors are clearly separated from privileged components KVM runs the hypervisor inside the host operating system The entire host operating system has to be trusted operators privileged components privileged components Linux + KVM virtualized system vulnerable hypervisor
6 Issues (2/2) The entire virtualized system cannot be managed by cloud operators Untrusted cloud operators cannot manage the hypervisor Managing the hypervisor and the rest independently is unrealistic Cryptography management is problematic It is not easy to securely manage cryptographic keys virtualized system operators modified client privileged components trusted admins trusted hypervisor remote host
7 VSBypass Achieve secure out-of-band remote management outside the virtualized system Run shadow devices outside the virtualized system Intercept I/O requests using transparent passthrough Process them in shadow devices Prevent information leakage and tampering virtualized system I/O shadow devices virtual devices user VM remote host transparent passthrough
8 System Architecture Run the entire virtualized system in an outer VM (cloud VM) using nested virtualization Shadow devices run outside the cloud VM Remote users access shadow devices instead of virtual devices The cloud VM and shadow devices run on top of the cloud hypervisor cloud VM user VM I/O shadow devices guest hypervisor remote host cloud hypervisor
9 Threat Model Cloud operators may be untrusted Have full control over the virtualized system including the hypervisor Cloud providers are trusted The TCB is the cloud hypervisor and shadow devices A few trusted admins maintain the TCB Admins form an administrative hierarchy operators user VM trusted shadow devices trusted admins guest hypervisor cloud hypervisor untrusted
10 Advantages (1/2) Difficult for cloud operators to attack the TCB The attack surface to the cloud hypervisor is much smaller Only the hardware interface is provided Support any virtualized systems The entire virtualized system is virtualized using the cloud VM VSBypass does basically not depend on the internals cloud VM privileged components Linux + KVM guest hypervisor cloud VM boundary of virtualization cloud hypervisor
11 Advantages (2/2) Cloud operators can manage the entire virtualized system VSBypass does not need to trust the guest hypervisor It enables clearly separating the responsibility of system management Cryptography is not necessary VSBypass does not rely on encryption to prevent information leakage Users can use the existing remote management software cloud VM privileged components existing client shadow devices guest hypervisor boundary of virtualization remote host cloud hypervisor
12 Shadow Devices Use virtual devices of a proxy VM as shadow devices Assign minimum resources to a proxy VM Pause a proxy VM after the boot Bind a proxy VM to a user VM using EPT Transparently perform secure out-of-band remote management by specifying proxy VM's ID user VM EPT proxy VM I/O shadow devices guest hypervisor cloud VM remote host cloud hypervisor
13 Transparent Passthrough Intercept an I/O request of a user VM in the cloud hypervisor A VM exit occurs directly to the cloud hypervisor By executing an instruction for port- and memory-mapped I/O Not forward the request to the guest hypervisor as usual The cloud hypervisor handles that request cloud VM I/O user VM instruction proxy VM shadow devices VM exit guest hypervisor cloud hypervisor
14 I/O Processing in Shadow Devices Redirect the intercepted I/O request to a shadow device Find a proxy VM from the trapped user VM using EPT Send that request as if the request is issued by the proxy VM Return the result to the user VM Intercept a completion event to the proxy VM Redirect that event to the cloud VM cloud VM user VM EPT proxy VM shadow devices guest hypervisor I/O request event cloud hypervisor
15 Sharing VRAM A user VM directly accesses VRAM in its main memory The cloud hypervisor cannot intercept that access with low overhead A shadow video card shares the VRAM of a user VM Process the VRAM as if it were the virtual device of the user VM Track updates of the VRAM using the log-dirty mechanism cloud VM user VM VRAM share shadow video card guest hypervisor updated area cloud hypervisor
16 Virtual Interrupts in Shadow Devices Redirect virtual interrupts caused in shadow devices to a user VM Deliver interrupts via the interrupt server in the virtualized system Virtual interrupts include no sensitive information Share a ring buffer using an ultracall [Miyama+ ESORICS'17] Receive interrupts by polling cloud VM interrupt server user VM shadow devices interrupt guest hypervisor cloud hypervisor
17 Experiments We conducted experiments to show the effectiveness of VSBypass Eavesdrop on I/O of out-of-band remote management Measure the performance of a virtual serial console and GUI remote access Comparison with the traditional system without nested virtualization user VM cloud VM vCPU: 3 Memory: 4 GB vCPU: 3 Memory: 1 GB Gigabit Ethernet CPU: Xeon E3-1270 Memory: 8 GB CPU: Xeon E3-1290 v2 Memory: 8 GB
18 Eavesdropping We eavesdropped on I/O data in virtual devices Record input/output characters in the virtual serial device Record keys in the virtual keyboard and screenshots in the virtual video card We could not obtain any data in VSBypass We could capture all data in the traditional system captured screen (traditional system) captured screen (VSBypass)
19 Performance of a Virtual Serial Console The response time between a character input and its echo- back in an SSH client VSBypass was 1.3 ms longer due to nested virtualization The throughput of outputting a text file to an SSH client VSBypass was almost the same 4 40 throughput (chars/ms) response time (ms) 3 30 2 20 1 10 0 0 Traditional VSBypass Traditional VSBypass
20 Performance of GUI Remote Access The response time between a key press and a screen update in a VNC client VSBypass was 13 ms longer due to the screen update The update time of user VM's screen in a VNC client VSBypass was 23 ms longer 70 50 response time (ms) 60 update time (ms) 40 50 30 40 30 20 20 10 10 0 0 Traditional VSBypass Traditional VSBypass
21 Related Work Device passthrough Enable direct access to physical devices from VMs Transparent passthrough in VSBypass is applied to virtual devices CloudVisor [Zhang+ SOSP'11] Encrypt the memory/disks of user VMs in the cloud hypervisor Protect no virtual devices for out-of-band remote management V-Met [Miyama+ ESORICS'17] Offload IDSes outside the virtualized system with nested virtualization Provide deep VM introspection to obtain the internal state of user VMs
22 Conclusion We proposed secure out-of-band remote management outside the virtualized system Run the virtualized system in a VM using nested virtualization Intercept I/O requests outside it using transparent passthrough Process them in shadow devices Future work Create/destroy proxy VMs with the boot/shutdown of user VMs Support the migration of user VMs with the state of shadow devices
