"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
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.
to post comments)