Can I use SELinux to add an extra layer of protection against 0-day VM escape exploits in KVM/QEMU?

Question

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?

EDIT:

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??

Answer 1

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.

wow! These are rare. In any case, the nature of 0days is that you can't know the mechanism before hand. So, the only actual course of action is to either a) not use functionality or b) keep your functionality up with the releases.

My question is, can I leverage SELinux to protect myself against such exploits?

Depends! The qemu executable runs in an SELinux context, and hence can only do what you allow it to do.

But if the 0day affects the KVM, kernel, side of things, there's no security boundaries there.

Or is there a better approach to protect against these attacks?

Honestly, unless you're likely to be analyzing things that state-budget sized experts leverage against high-value targets, I'd recommend dialing down the worries, and just use the most up to date release of Linux. Linux releases regularly exactly because that allows them to regularly ship patches to functionality that might or has been exploited.

If you're likely to be analyzing things that state-budget sized expert groups leverage against high-value targets (say, the whole of AWS, or the NSA,…), then why are you not working on a dedicated computer in an air-gapped network?