When taking advantage of virtualization to flexibly and conveniently manage workloads, a new security model should be considered. In a traditional environment, where a single operating system runs on it's own private hardware, the central attack vector is through the network. However, in a virtualized environment, where multiple guest operating systems are sharing the same host operating system and hardware, the attack vector is not only external to the system and through the network, but also internal from within the system. In this post, we'll touch on a number of steps that can be taken to minimize the security exposures presented in your KVM environment.
For more details on the topics discussed below, please take a look at the KVM Security blue print located at: http://publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp?topic=/liaat/liaatseckickoff.htm. It contains a thorough discussion on these topics, including several configuration examples.
Minimize vulnerabilities by minimizing the TCB
The trusted computing base (TCB) is the combination of hardware and software in a computer system that is trusted to enforce security for the system. The TCB must be verified and maintained regularly to make sure it is correct. A smaller TCB naturally results in a smaller chance of having a bug in the TCB. Therefore, the size of the TCB has a direct effect on the security quality of KVM. To reduce the TCB, for example, you can turn off unused daemons and remove unnecessary packages from the host operating system.
Separate host and guest
networks to protect the host
The security of a KVM host can be increased by isolating the host network from the network used for guests. Typically, users who access the host are privileged while users who access guests are not privileged. This separation not only isolates the host and guest operating systems, but also works to prevent a malicious unprivileged user in a guest from attacking the host operating system.
Prevent MAC address
A root user in a guest operating system can change the MAC address of its network device. By enforcing a single MAC address for each guest network device, MAC address spoofing can be prevented. Preventing MAC address spoofing stops a rogue root user in a guest from masquerading as another guest.
traffic within a bridged network
A common KVM deployment employs a Linux network bridge, which enables incoming and outgoing network traffic to and from guests. In order to provide data separation and security between network traffic within the bridged LAN, the network bridge can be extended to employ VLAN tagging. VLAN tagging can be deployed to filter traffic, where packages arriving at a particular VLAN that do not carry a specific VLAN ID tag can be filtered out.
Isolate virtual machines
from each other
sVirt is a libvirt technology that combines NSA-developed SELinux technology with KVM to provide Mandatory Access Control (MAC) guest isolation. Mandatory Access Control provides security controls that a subject cannot override. The MAC security provided by sVirt limits a guest process to accessing only the data (image files) that belong to it. sVirt is available out of the box on Red Hat Enterprise Linux (since RHEL 4) where SELinux is enabled by default.
Be sure that storage
devices are secure
When storing guest disk images in a non-default location, it is important to enable the same directory and file permissions, and the same SELinux labels, as those that protect disk images stored in the default (/var/lib/libvirt/images) directory. Additionally, if you plan to store guest disk images on an NFS mount, it is important to understand that NFS does not support file labels, and therefore does not support sVirt isolation of guest image files.
Perform secure remote
When performing remote management, the client and server should first be authenticated and data that is transmitted over the wire should be encrypted whenever possible. With the exception of Spice, or accessing the VNC console with a tool other than virt-viewer (where communication is directly with KVM), all guest management is performed through libvirtd daemon clients such as virsh, virt-viewer, and virt-manager. When using these clients remotely, data can be transmitted via secure encrypted connections such as SSH tunnels or secure TLS. In addition to encryption, TLS provides authentication capabilities. virsh also supports SASL authentication and encryption. If accessing the VNC console with a tool other than virt-viewer, connections can be initiated with SSH encryption.
Spice can be used to provide high-quality remote access to KVM and supports OpenSSL authentication and encryption. Spice is not described in the KVM Security blue print that was referenced earlier in this post. For more information on Spice, see: http://www.spice-space.org/.
Limit virtual machine
resources with control groups (cgroups)
Control groups (cgroups) can be used to limit the resources (such as processing power, memory, disk, and networking bandwidth) that a guest operating system can consume. This is an important feature that can prevent a breached guest from over-consuming resources and causing a denial-of-service situation.
Protect data at rest
with disk-image encryption
All images belonging to a guest that is not running should be encrypted. If an attacker were to compromise the host, encryption of data at rest would help prevent an offline attack.
Audit host and guests to
obtain valuable forensic information
It is important to track host and guest changes and interactions at all times, in case a security breach does occur. By auditing host and guests, valuable forensic information can be tracked on an ongoing basis.
When running a virtualized environment, security is a critical part of the solution that cannot be overlooked. So be sure to evaluate and consider all of security features mentioned above before deploying KVM.
Security Software Engineer
IBM Linux Technology Center