Description of problem: Running kvm guests does not need root permissions and the restriction on starting it with root privileges should be dropped. A new group, "vm" can be created and /dev/kvm can be given group ownership of 'vm'. Users can be added to the vm group to enable them to run VMs. Giving root privileges to guests is insecure and misbehaving guests can take advantage of this.
There are two issues here: 1) Unprivileged users should be able to start KVM guests I don't like the group idea so much. How do e.g. virt-manager users know they need to be added to a group? If it's safe to allow unprivileged users to create KVM guests, why not open the permissions of /dev/kvm to all users? Also, would change the Virtual Machine Manager menu item to not run virt-manager as root by default anymore? e.g. running it as root may still be preferable so as to use tap based networking instead of slirp based networking 2) KVM guests started by root should run as an unprivileged user to limit the impact of any security exploit Would also need libvirtd to actually run the process as the new user. That user would need to be given write permission on image files. Are there no other permission issues? e.g. tap networking would be an issue if it wasn't for the fact that libvirtd creates the tapfd. Audio?
There are actually many things impacted by this requirement, so I think we'll need several bugs to track this - We have already reserved a group called 'kvm' in the setup package, so no need for yet another called 'vm'. The /dev/kvm should be chgrp kvm by default. That said I agree with Mark that it'd be desirable to also make it possible to just any normal user access to /dev/kvm out of the box, so libvirt's per-user qemu:///session connection can be used - Making virt-manager run as non-root is completely unrelated to running KVM guests as non-root. The only reason it still runs as root is because it is still directly creating storage files. Once virt-manager has fully switched over to the libvirt storage APIs, it will always be run unprivileged, doing all privileged operations via libvirt APIs, authenticated with PolicyKit. - For libvirt, there are two connections to consider, the system wide instance, qemu:///system where libvirtd itself runs as root, so we'd need to make the QEMU instances unprivileged. For the per-user instance, qemu:///session, both libvirtd and QEMU already run with normal user privs - so we first need to work out /dev/kvm (and /dev/kqemu) policy - Networking for qemu:///system is easy - libvirtd creates the TAP devices, adds it to the bridge, and passes it to KVM. We do however need to make sure network device hotplug alllows us to pass a live FD to the monitor console using SCM_RIGHTS + recvmsg(), so we can hotplug NICs with a pre-setup TAP dev - Networking for qemu:///session is hard, for outbound network, there is only SLIRP. For direct VM-to-VM there are various virtual options, like QEMU's builtin UDP-UDP virtual nets, or VDE. Or we can explore a setuid TAP device helper ? - With qemu:///system, for actually dropping privs, there are two options - either KVM can start as root and then drop privs, or libvirt can drop privs between fork & exec of the KVM / QEMU binary - the latter has advantage that it'll work with all existing QEMU binaries which is very desirable. It also means libvirt can *guarentee* that the QEMU binary is unprivileged, rather than having to trust it to drop privs. - For disks, libvirtd will likely need to manually chown/chgrp any files / devices that are backing KVM guests before running it, since the UID KVM will run as will likely not have privs to access these. The same issue when hot-plugging disks. - For other devices (audio, usb, etc), one of these two strategies can generally be applied - either opening the resource & passing an FD, or chown'ing it - Have to check whether PCI hotplug will still work as expected, if all VMs are running unprivileged ? - Finally, on a related topic, all KVM/QEMU instances will soon be put into their own CGroup. This will allow per-VM resource tuning, and if a we run unprivileged too, then we can use the device ACL cgroup controller, to isolate VMs from each other's block devices.
See: https://fedoraproject.org/wiki/Features/VirtPrivileges We've got most of this done, just need to split out the last items into their own bugs (In reply to comment #2) > There are actually many things impacted by this requirement, so I think we'll > need several bugs to track this > > - The /dev/kvm should be chgrp kvm by default. > - it'd be desirable to also make it possible to just any normal user > access to /dev/kvm out of the box > - so we'd need to make the QEMU instances unprivileged > - We do however need to make sure network device hotplug alllows us to pass > a live FD to the monitor console using SCM_RIGHTS + recvmsg(), so we can > hotplug NICs with a pre-setup TAP dev > - libvirt can drop privs between fork & exec of the KVM / QEMU binary > - For disks, libvirtd will likely need to manually chown/chgrp any files / > devices that are backing KVM guests before running it > - Finally, on a related topic, all KVM/QEMU instances will soon be put into > their own CGroup. Done in F-12 > - Once virt-manager has fully switched over to the libvirt storage APIs, it will always be run unprivileged Done in F-11 > - Networking for qemu:///session is hard, for outbound network, there is only > SLIRP. For direct VM-to-VM there are various virtual options, like QEMU's > builtin UDP-UDP virtual nets, or VDE. Or we can explore a setuid TAP device > helper ? Not done. > - For other devices (audio, usb, etc), one of these two strategies can > generally be applied - either opening the resource & passing an FD, or > chown'ing it I don't think we've done anything about audio or usb > - Have to check whether PCI hotplug will still work as expected, if all VMs > are running unprivileged ? Do you mean PCI device assignment or ... ?
Audio is just a mess in general, so I've still ignored it. qemu:///session networking is just left for another day. With USB, libvirt will chown() the USB device before launching QEMU/hotplugging. Likewise for PCI disk device hotplug. It will chown the PCI resources in sysfs for PCI dev assignment at time of starting QEMU. libvirt doesn't appear todo hotplug for PCI dev assignment, but that could eb easily handled.
I think this is pretty much done in Fedora 12 now Switching to qemu:///session by default is another matter