Created attachment 525638 [details] 65-vfio.rules This is a feature request. Please add the attached udev file for VFIO devices to the qemu ebuild. With default device permissions, VFIO device permissions are set up as: drwxr-xr-x 2 root root 80 Mar 25 18:38 /dev/vfio crw------- 1 root root 247, 0 Mar 25 18:38 /dev/vfio/1 crw-rw-rw- 1 root root 10, 196 Mar 25 18:37 /dev/vfio/vfio This is potentially unsafe as it allows any user to write to /dev/vfio/vfio. It also restricts access to /dev/vfio/1 to root which prevents non-root users from performing vga-passthrough. The attached rules file, however, alters the permissions to become the following: drwxr-xr-x 2 root root 80 Mar 25 18:38 /dev/vfio crw-rw---- 1 root kvm 247, 0 Mar 25 19:04 /dev/vfio/1 crw-rw---- 1 root kvm 10, 196 Mar 25 19:04 /dev/vfio/vfio This relaxes permissions on /dev/vfio/1 to allow any user of the kvm group to perform vga-passthrough. Furthermore, it tightens the permissions on /dev/vfio/vfio to restrict access to only kvm users. I believe this would be a better configuration as it removes the need to be root to perform vga-passthrough, and ensures access is restricted to users trusted to set up such VMs (i.e. users of the kvm group)
Created attachment 525640 [details] qemu-2.11.1-r53.ebuild An updated version of the qemu-2.11.1-r52.ebuild. The only difference between this one and -r52 is it includes the needed line to install the proposed vfio udev rules file.
yes, this is a pretty huge oversight and would be nice to correct the default settings. i have reservation about the use of 'kvm' group since xen backend also works with vfio but i'm not sure that's the level of pedantic precision we should aim for. another good idea would be to set the default group to 'kvm' in qemu.conf for libvirt, since otherwise it runs as root:root.
Exposed pass-through devices with world writable bits should be tagged as a vulnerability. Removal of those is a no-brainer. Assigning kvm (or another) group as owner of the vfio node(s) aligns with the best practice of restricting the device while not requiring elevation to root. Existing users may have rules in place already, so a post-emerge message would be appropriate. That xen also uses the device vfio device node is brought up by comment #2. While qemu and xen may be installed on the same system, it is probably is not common to do so. It does leave the questions of whether a more universal group should be used for both virtualization methods and/or if the xen (or another) ebuild should be modified as well to keep ownership of the node consistent between methods. Possible parent ticket for addressing vfio ownership on both virtualization platforms? However vfio group ownership is modified, it + comment #2 regarding execution of libvert as kvm (or a virtualization) group would pair and nicely and easily move kvm support a notch forward with regards to security.
Confirmed. Starting any VM with PCI-passthrough, or simply modprobing vfio-pci creates a device node with crw-rw-rw- 1 root root 10, 196 Mar 27 08:44 /dev/vfio/vfio This is terrible. The default should be "crw-------". I will add said rule to qemu immediately - but we should also investigate why modprobing vfio-pci creates the /dev/vfio/vfio device node with incorrect permissions. CC'ing kernel, udev and security.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2fc1bc6c7b1f41a3a7df74ce8e170996eb7e36d9 commit 2fc1bc6c7b1f41a3a7df74ce8e170996eb7e36d9 Author: Matthias Maier <tamiko@gentoo.org> AuthorDate: 2018-03-27 15:10:52 +0000 Commit: Matthias Maier <tamiko@gentoo.org> CommitDate: 2018-03-27 15:44:04 +0000 app-emulation/qemu: add rule to fix permissions on /dev/vfio/vfio The device node /dev/vfio/vfio gets created on modprobing the vfio* modules. This happens in particular on demand when a qemu vm with PCI passthrough is started up. The default permissios for the freshly created device node is crw-rw-rw- 1 root root 10, 196 Mar 27 08:44 /dev/vfio/vfio This is terrible. This patch adds an udev rules and makes sure that the device node has rw permissions for user root, and group kvm (and no permissions for all). This fixes - startup when a qemu-kvm is started as non-root (provided the user is in group kvm, which is our current policy for accessing /dev/kvm, etc., anyway). - work around this security vulnerability, where /dev/vfio/vfio is created with world writable permissions upon modprobe. [1] Thanks to username234, Kash Pande, Ted Rodgers for discovery and patch! [1] Steps to reproduce: % ls -la /dev/vfio/vfio crw------- 1 root root 10, 196 Mar 27 15:40 /dev/vfio/vfio % modprobe vfio % ls -la /dev/vfio/vfio crw-rw-rw- 1 root root 10, 196 Mar 27 15:41 /dev/vfio/vfio [2] I cannot find an udev rule installed by libvirt/qemu/... that triggers these permissions. Bug: https://bugs.gentoo.org/651668 Package-Manager: Portage-2.3.24, Repoman-2.3.6 RepoMan-Options: --force app-emulation/qemu/files/65-vfio.rules | 2 ++ app-emulation/qemu/{qemu-2.11.1-r1.ebuild => qemu-2.11.1-r2.ebuild} | 1 + 2 files changed, 3 insertions(+)}
According to the kernel documentation, mode 0666 is expected to be set because /dev/vfio/vfio alone does not provide any capabilities. Checked with other distributions [1]. Unassigning security and reverting. Thanks to dwfreed for pointing this out. [1] https://www.kernel.org/doc/Documentation/vfio.txt
