Description of problem:
Historically libvirt has had a monolithic daemon (libvirtd) that runs all the libvirt drivers, and has a virtd_t policy context. Due to the huge range of features libvirtd has, the virtd_t context offers very little, if any, meaningful security protection.
Relatively recently we introduced virtlockd and virtlogd for some specific helper tasks, which gained their own selinux context and policy rules.
In the forthcoming release of libvirt we have gone a step further and introduced a lot of new daemons, one for each driver libvirt has.
So going forward we now have
Hypervisor drivers
- virtqemud (QEMU/KVM)
- virtlxcd (LXC)
- virtvzd (VZ / Virtuozzo)
- virtxend (Xen)
- virtvboxd (VirtualBox)
- virtbhyved (FreeBSD only)
Secondary drivers
- virtstoraged (host storage mgmt)
- virtnetworkd (virtual network mgmt)
- virtinterface (network interface mgmt)
- virtnodedevd (physical device mgmt)
- virtsecretd (security credential mgmt)
- virtnwfilterd (ip[6]tables/ebtables mgmt)
We are thus going to need new selinux contexts added for each of these daemons.
The best case is to figure out the minimal possible permissions for each of these daemons. This is likely a non-trivial amount of effort.
A quick hack would thus be to at least make each of these daemons have a context which has the same permissions granted as the existing "virtd_t" context.
Then we can work to identify & remove undesirable permissions to get tighter control over each daemon.
Alternatively we can try todo something strict upfront.
I don't mind, as long as we don't have them running unconfined_t & am happy to assist in understanding the SELinux rules we need for each
These new daemons will appear in libvirt 5.7.0 which is due to be released Sep 1, and will go into Fedora 32 rawhide, and likely RHEL-8.2 (advanced virt module)
Version-Release number of selected component (if applicable):
selinux-policy-3.14.3-18.el8.noarch
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2020:1773