LinuxCon: Secure virtualization with sVirt

"I'm the rain in the cloud" is how Red Hat's Dan Walsh described himself at the beginning of his LinuxCon talk. There is much talk of "cloud computing" these days, but there has not been too much attention paid to the security aspects. Running multiple guest operating systems on the same hardware is "one of the scariest things you can do" from a security point of view, he said. sVirt was developed to combat the problem by applying SELinux mandatory access controls to restrict what guests can do—even if they break out of their containment and can access the Linux host OS.

Before virtualization, servers were separated by network connections, so a misbehaving server would have to launch a network-based attack to break into another server. There are lots of tools available to administrators that will alert or thwart network attacks, but when the servers are running on the same hardware, there is another line of attack: the hypervisor itself. Guests that can perform unauthorized actions on the host OS or hypervisor may be able to access information that is only supposed to be available to a different guest.

These are not theoretical attacks, Walsh said, as there have been successful attacks against Xen and others. Hypervisor vulnerabilities are the "number one goal" of the attacker community right now. The attack against Xen was able to subvert the SELinux policies that were in place on Red Hat Enterprise Linux (RHEL) specifically to stop that kind of attack. Those policies failed because the SELinux labeling of Xen processes and data were left up to administrators—something that sVirt is meant to fix.

Walsh pointed out that all guest OSes typically run as the same user in the Linux host. So, any exploit means that guests can access any other guest on that host. In the cloud computing scenario, users have no idea who else is sharing their machine, so it could easily be a competitor or someone with a malicious intent. But, enforcing separation between processes is a job that SELinux is good at.

In an SELinux-enabled system, processes and data both get labeled based on how they are allowed to be used. Since virtual machines are processes and their filesystem images are files on the host, proper application of SELinux labels—along with rules to govern the label interactions—will effectively disallow guests from unauthorized access to other guests. The host kernel enforces those rules so, as long as the kernel itself is uncompromised, rogue guests are confined.

As they learned from the Xen compromise, leaving the labeling up to administrators does not work, Walsh said, so they added dynamic labeling into libvirt. sVirt uses a largely unused field—for multi-category security (MCS)—in the SELinux label and generates a random unused value for that field. It labels the image file, then launches the virtual machine using that same label.

Using the MCS field allows the same SELinux rules to be used for all of the guests, but still restrict guests such that each guest can only access its process and data. When the guest exits, the guest image is then relabeled back to its original value. Different labels are used for shared images, depending on whether they are shared as read-only or read-write, which will allow administrators some flexibility while still restricting access to unrelated guest images.

Starting with Fedora 11, virt-manager will, by default, handle the automatic relabeling of virtual machines and data, Walsh said. One would guess that RHEL 6 will have that capability as well.

While it is certainly not a panacea for security in a virtualized environment, sVirt does provide some useful separation between guests. There is still cause to be concerned about potential kernel vulnerabilities that would allow end runs around SELinux, but sVirt reduces the exposure surface. As part of a multi-layered defense, sVirt effectively narrows the cracks that attackers can slip through.