sVirt in Red Hat Enterprise Linux OpenStack Platform

Posted: November 9, 2013 in Cloud Computing, Security

A lot of people are probably looking at all of the OpenStack offerings that are out there today and wondering “Which one should I use?”  or “What feature makes one company’s OpenStack better the others?”  One feature that causes Red Hat’s offering to stand out among the others is the inclusion of sVirt.  In the simplest terms, sVirt is SELinux for virtualization.  It implements Mandatory Access Controls to provide protection from potential attacks that could result in hosts or virtual machine instances being compromised.  Other Red Hat products take advantage of sVirt as well, including the stand alone KVM hypervisor that comes with Red Hat Enterprise Linux and Red Hat Enterprise Virtualization.

How sVirt Works

In a virtualized environment, the potential exists for a virtual machine to become compromised and be used as a platform to attack the host hypervisor, other virtual machines or even access other virtual disk files or volumes that the host has access to.  This is illustrated in the below image.  Even with SELinux running in a VM, the attack could still take place.  Imagine how quickly an attacker could create havoc on your virtual infrastructure or cloud environment if the attack is not quickly detected and defeated in some manner.


For sVirt to work, SElinux must be running (aka enforcing) on the host system.  Once it is running, SELinux will assign each virtual machine a unique SELinux label when the virtual machine is instantiated.  The process that the virtual machine runs as well as its corresponding disk file or volume receive the same label.  Virtual disks or volumes that are not being used receive a generic label indicating that they are virtual disk type files but are not currently running.  In the figure below both virtual machine processes and virtual disk volumes are labeled as “svirt_t:MCS1” and “svirt_t:MCS2” respectively.  The MCS1 and MCS2 labels are representative of the actual label that would appear as “s0:cX,cY” where X and Y are randomized values between 0 and 1023.  The virtual disk volume that the host has access to, but is not running is labeled as appropriately well.


SELinux works by using type enforcement.  That means that if a process is labeled then it can only access objects, files, etc. that have a compatible label.  With the virtual machine processes and corresponding virtual disk volumes labeled with the same unique label, SELinux is now able ensure that only the virtual machine that is associated with the virtual disk volume can access it.  At the same time SELinux prevents virtual machine processes from accessing any parts of the host that do not have a compatible label.  This is what gives sVirt it’s ability to stop malicious activity from happening.


sVirt in Action

Lets take a look at how Red Hat OpenStack integrates with sVirt.

First, log into an OpenStack Nova compute node as root.  Executed the “getenforce” command shows that SELinux is in enforcing mode and the “id” command verifies that the user is root (UID=0).


Next, run “ps auZ | grep qemu-kvm” and use grep to filter the results as shown below.  You can see in the results the MCS security context for two instances running on this host.  The instance called “instance-00000022” has an MCS context of s0:c379,c680 while “instance-00000021” has the MCS context of s0:c41,c363 assigned to it


Looking at the labels of files that make up the virtual disks for these two instances confirms that sVirt has labeled them to be the same as the associated instance process.


Now, lets explore what would happen if a virtual machine process broke out of sVirt confinement and was able to access objects on the host server.  To do this, I will copy the bash command library and change its security context so that a VM process can execute it.  Then I will change my shell so that I am executing the new svirt-bash shell using the same style of security context as a running virtual machine instance.  This is done using the “runcon” command.  Below are the steps that are needed to set things up.


You probably noticed the permission denied that occurred after the runcon command was executed.  This is fine – SELinux is doing its job since I am no longer in a shell using the normal root security context.  Compare what is displayed now versus what was displayed earlier when I ran the id command.


I am still root (UID=0) but as you can see, my security context is now exactly like that of a virtual machine instance.  Since my label is not compatible with the files that I am trying to access, I get permission denied errors.  We can open another window and see what kind of SELinux alerts have being generated.


From the above image, we can see that my source context (scontext) did not match the target context (tcontext) so my access was denied to .bashrc and .bash_history.

The svirt_t processes obviously cannot see root’s files, but what about other files?  How about the VM disk files?


Permission denied all over the place.  Switching shells did not work, changing directories did not work either.  Even when I know the path that I want to get to, I am unable to see anything is there.

Let’s see if the “ps” command that we ran earlier will work.  The information that is returned could allow an attacker to gather some information on what other processes are running and maybe take advantage of an exploit for one of them.


Nothing there either.  According to the results that are returned, the only processes that are running are my own.  I am effectively confined to my own process.

What happens if SELinux is in permissive mode?  Let’s try by opening another connection to the server and setting it into permissive mode with the “setenforce” command.


With SELinux in permissive mode, protection is no longer provided.  I can now run the same ps commands as before despite still having the svirt_t security context applied to my account.


That is pretty scary though, so let’s make sure SELinux is back in enforcing mode by again using the setenforce command.


Now things are protected again and I am back to only being able to see my processes.



Security in the cloud has become a pretty hot topic with many vendors and individuals wondering what is the best approach.  Red Hat’s sVirt is a tried and true technology.  It is specifically designed to limit what can happen should a process go rogue and begin to attack other parts of the infrastructure.  It should not replace other technology such as firewalls since the best defense is a layer defense in most cases.

I hope that his post was a good introduction to sVirt for you and that we understand the benefits of using it in your cloud environment.

  1. Good day! Do you use Twitter? I’d like to follow you if that would be ok.
    I’m undoubtedly enjoying your blog and look forward to new posts.

  2. chen says:

    Hello,my friends.there exists so many host machines In cloud environment,however,selinux is deployed on one host machine,how can we handle manage the policy???thanks!

    • tedbrunell says:

      The SELinux is installed as part of OpenStack. From a user and admin perapective, it is transparent and does not need any management even across thousands of hosts.

  3. noureddine says:

    i’ve hearda lot about securing hypervisors so that I became afraid, what i understand that selinux does not require admin intervention since svirt generates the automatic labels, so why there is to much debate about svirt, on the other hand to put selinux in mode enforcing is enough ??

    • tedbrunell says:

      I think that people might be remembering how rough SELinux was when it was first released in RHEL 4. Since then a lot of work has gone into it to make it transparent to users. You are correct that SELinux (and sVirt) have made securing hypervisors easier by automatically assigning labels to VMs. The same applies to containers. Maybe I will write about that some day…

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s