SELinux to the Rescue If you have been following the news lately you might have heard of the "Venom" vulnerabilty. Researchers found a bug in Qemu process, which is used to run virtual machines on top of KVM based linux machines. Red Hat, Centos and Fedora systems were potentially vulnerable. Updated packages have been released for all platforms to fix the problem. But we use SELinux to prevent virtual machines from attacking other virtual machines or the host. SELinux protection on VM's is often called sVirt. We run all virtual machines with the svirt_t type. We also use MCS Separation to isolate one VM from other VMs and thier images on the system. While to the best of my knowlege no one has developed an actual hack to break out of the virtualization layer, I do wonder whether or not the break out would even be allowed by SELinux. SELinux has protections against executable memory, which is usually used for buffer overflow attacks. These are the execmem, execheap and execstack access controls. There is a decent chance that these would have blocked the attack. # sesearch -A -s svirt_t -t svirt_t -c process -C Found 2 semantic av rules: allow svirt_t svirt_t : process { fork sigchld sigkill sigstop signull signal getsched setsched getsession getcap getattr setrlimit } ; DT allow svirt_t svirt_t : process { execmem execstack } ; [ virt_use_execmem ] Examining the policy on my Fedora 22 machine, we can look at the types that a svirt_t process would be allowed to write. These are the types that SELinux would allow the process to write, if they had matching MCS labels, or s0. # sesearch -A -s svirt_t -c file -p write -C | grep open allow virt_domain qemu_var_run_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; allow virt_domain svirt_home_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; allow virt_domain svirt_tmp_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; allow virt_domain svirt_image_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; allow virt_domain svirt_tmpfs_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; allow virt_domain virt_cache_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; DT allow virt_domain fusefs_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; [ virt_use_fusefs ] DT allow virt_domain cifs_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; [ virt_use_samba ] ET allow virt_domain dosfs_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; [ virt_use_usb ] DT allow virt_domain nfs_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; [ virt_use_nfs ] ET allow virt_domain usbfs_t : file { ioctl read write getattr lock append open } ; [ virt_use_usb ] Lines beginning with the D are disabled, and only enabled by toggling the boolean. I did a video showing the access avialable to an OpenShift process running as root on your system using the same technology. Click here to view. SELinux also blocks capabities, so the qemu process even if running as root would only have the net_bind_service capabilty, which allows it to bind to ports < 1024. # sesearch -A -s svirt_t -c capability -C Found 1 semantic av rules: allow svirt_t svirt_t : capability net_bind_service ; Dan Berrange, creator of libvirt, sums it up nicely on the Fedora Devel list: "While you might be able to crash the QEMU process associated with your own guest, you should not be able to escalate from there to take over the host, nor be able to compromise other guests on the same host. The attacker would need to find a second independent security flaw to let them escape SELinux in some manner, or some way to trick libvirt via its QEMU monitor connection. Nothing is guaranteed 100% foolproof, but in absence of other known bugs, sVirt provides good anti-venom for this flaw IMHO." Did you setenforce 1?