My host is Fedora, and I want to add an extra layer of protection against 0day KVM/QEMU exploits that execute code on the host. For example there have been CVEs where if we run a specially crafted malicious windows executable on the windows VM as admin, it would execute code on the host.

I analyze malware from time to time and need to execute unknown malwares so can't do anything about that, and I don't want to buy a separate computer for that either.

My question is, can I leverage SELinux to protect myself against such exploits? Or does KVM/QEMU already use SELinux to protect against such attacks? Or is there a better approach to protect against these attacks?


The following is output of semanage boolean -l | grep virt In my updated Fedora 39 :

virt_lockd_blk_devs            (off  ,  off)  Allow virt to lockd blk devs
virt_qemu_ga_manage_ssh        (off  ,  off)  Allow virt to qemu ga manage ssh
virt_qemu_ga_read_nonsecurity_files (off  ,  off)  Allow virt to qemu ga read nonsecurity files
virt_qemu_ga_run_unconfined    (off  ,  off)  Allow virt to qemu ga run unconfined
virt_read_qemu_ga_data         (off  ,  off)  Allow virt to read qemu ga data
virt_rw_qemu_ga_data           (off  ,  off)  Allow virt to rw qemu ga data
virt_sandbox_share_apache_content (off  ,  off)  Allow virt to sandbox share apache content
virt_sandbox_use_all_caps      (on   ,   on)  Allow virt to sandbox use all caps
virt_sandbox_use_audit         (on   ,   on)  Allow virt to sandbox use audit
virt_sandbox_use_fusefs        (off  ,  off)  Allow virt to sandbox use fusefs
virt_sandbox_use_mknod         (off  ,  off)  Allow virt to sandbox use mknod
virt_sandbox_use_netlink       (off  ,  off)  Allow virt to sandbox use netlink
virt_sandbox_use_sys_admin     (off  ,  off)  Allow virt to sandbox use sys admin
virt_transition_userdomain     (off  ,  off)  Allow virt to transition userdomain
virt_use_comm                  (off  ,  off)  Allow virt to use comm
virt_use_execmem               (off  ,  off)  Allow virt to use execmem
virt_use_fusefs                (off  ,  off)  Allow virt to use fusefs
virt_use_glusterd              (off  ,  off)  Allow virt to use glusterd
virt_use_nfs                   (on   ,   on)  Allow virt to use nfs
virt_use_pcscd                 (off  ,  off)  Allow virt to use pcscd
virt_use_rawip                 (off  ,  off)  Allow virt to use rawip
virt_use_samba                 (off  ,  off)  Allow virt to use samba
virt_use_sanlock               (off  ,  off)  Allow virt to use sanlock
virt_use_usb                   (on   ,   on)  Allow virt to use usb
virt_use_xserver               (off  ,  off)  Allow virt to use xserver

Can someone explain which of these do I need to turn on or off to add extra protection against KVM/QEMU exploits without making the Windows VM unusable? My basic usage of the Windows VMs is that I code in some of them, and I run malware in others for analysis, and I don't need Internet connection for VMs, are these rules configured properly for this case or I can make it more secure?

Basically, If you were tasked with securing KVM/QEMU by using SELinux rules, which SELinux rules would you turn off or on to make it more secure?

There are literally 0 info on some of the above rules on the internet, for example what the hell does "Allow virt to rw qemu ga data" even mean? Ga Data??

EDIT2: My current SELinux config in qemu.conf is in the following, does this mean currently SELinux is not being used? then why my qemu process seems to have a svirt security context : system_u:system_r:svirt_t:s0:c740,c772 ?

#security_driver = "selinux"
  • 1
    Did you see my answer? There's no magical SELinux boolean that stops all threats, because this is a complex problem. As I already said, the sVirt project uses Multi-Category Security labels to tackle this. Their ideas and the related settings are well-documented, and you can control exactly what the VMs can and cannot access. If you don't want that, what do you want? By the way, "ga" stands for the QEMU guest agent.
    – Ja1024
    Commented Mar 21 at 6:38
  • @Ja1024 What are the steps that I need to do in order to integrate sVirt with my current KVM/QEMU? And this project seems to be really old, does it still work with the latest KVM/QEMU versions? Does sVirt simply add new SELinux rules?
    – OneAndOnly
    Commented Mar 21 at 14:52
  • sVirt isn't old, it's part of the current libvirt library. If you install libvirt on a SELinux-enabled OS and use it to create and start QEMU VMs, it should use sVirt by default (but double-check that). sVirt modifies the creation of QEMU processes and images to add SELinux Multi-Category labels like system_u:object_r:svirt_image_t:MCS, where MCS is a randomly generated per-VM category.
    – Ja1024
    Commented Mar 21 at 18:56
  • @Ja1024 Thanks for the info, How can I check if my fedora already is using svirt? The security context for qemu process right now is : system_u:system_r:svirt_t:s0:c740,c772. Does this mean fedora uses svirt by default? And what is the meaning of the last part of it : s0:c740,c772?
    – OneAndOnly
    Commented Mar 24 at 4:47
  • @Ja1024 Also security_driver line is commented in qemu.conf is commented in my qemu.conf, so why does it seems like svirt is being used already based on qemu security context?
    – OneAndOnly
    Commented Mar 24 at 4:51

1 Answer 1


You can and should use SELinux to protect the host from VM exploits and also isolate VMs from each other. The svirt project uses the Multi-Category Security (MCS) feature of SELinux to implement exactly this kind of isolation. For each VM, sVirt automatically generates a unique MCS label and assigns it to both the VM process and the image. This prevents the VMs from accessing each other or any resource on the host that isn't explicitly labelled as usable for the VM.

svirt is part of libvirt and can be enabled via security_driver = "selinux" in the file /etc/libvirt/qemu.conf.

  • Correct me if I'm wrong, svirt will help with exploits that target the user space part of the hypervisor. If a guest can exploit the host kernel, SELinux can be bypassed. Of course a correctly set SELinux domain will make accessing the exploit vectors hard or impossible, but still, if the attacker can exploit the kernel part of the hypervisor (maybe even by pivoting a secondary stage in the context of the userspace hypervisor, which sVirt doesn't help preventing), then all bets are off. Commented Mar 21 at 14:59
  • It depends on the exact kernel vulnerability whether or not SELinux can be bypassed. But it's true that SELinux cannot stop every exploit.
    – Ja1024
    Commented Mar 21 at 18:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .