For Ubuntu, if the issue is causing a lot of issues, I'm open to a distro patch that enables the access by default on the condition that /etc/libvirt/qemu.conf is adjusted to have a comment in the vicinity of:
#user = "root"
...
#group = "root"
with something along the lines of the following:
# By default libvirt runs VMs as non-root and uses AppArmor profiles
# to provide host protection and VM isolation. While AppArmor
# continues to provide this protection when the VMs are running as
# root, /dev/vhost-net access is allowed by default in the AppArmor
# security policy, so malicious VMs running as root would have
# direct access to this file. If changing this to run as root, you
# may want to remove this access from
# /etc/apparmor.d/abstractions/libvirt-qemu. For more information,
# see:
# https://launchpad.net/bugs/1815910
# https://www.redhat.com/archives/libvir-list/2019-April/msg00750.html
#user = "root"
...
#group = "root"
I've stated my preference for upstream: https:/ /www.redhat. com/archives/ libvir- list/2019- April/msg00750. html
For Ubuntu, if the issue is causing a lot of issues, I'm open to a distro patch that enables the access by default on the condition that /etc/libvirt/ qemu.conf is adjusted to have a comment in the vicinity of:
#user = "root"
...
#group = "root"
with something along the lines of the following:
# By default libvirt runs VMs as non-root and uses AppArmor profiles d/abstractions/ libvirt- qemu. For more information, /launchpad. net/bugs/ 1815910 /www.redhat. com/archives/ libvir- list/2019- April/msg00750. html
# to provide host protection and VM isolation. While AppArmor
# continues to provide this protection when the VMs are running as
# root, /dev/vhost-net access is allowed by default in the AppArmor
# security policy, so malicious VMs running as root would have
# direct access to this file. If changing this to run as root, you
# may want to remove this access from
# /etc/apparmor.
# see:
# https:/
# https:/
#user = "root"
...
#group = "root"