Bug 481260 - RFE: allow kvm guests to be run as an unprivileged user
RFE: allow kvm guests to be run as an unprivileged user
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Veillard
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F13VirtTarget
  Show dependency treegraph
 
Reported: 2009-01-23 01:30 EST by Amit Shah
Modified: 2009-09-24 07:46 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-24 07:46:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Amit Shah 2009-01-23 01:30:39 EST
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.
Comment 1 Mark McLoughlin 2009-01-23 03:05:11 EST
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?
Comment 2 Daniel Berrange 2009-01-23 05:55:32 EST
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.
Comment 3 Mark McLoughlin 2009-08-10 11:19:13 EDT
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 ... ?
Comment 4 Daniel Berrange 2009-08-10 11:29:05 EDT
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.
Comment 5 Mark McLoughlin 2009-09-24 07:46:02 EDT
I think this is pretty much done in Fedora 12 now

Switching to qemu:///session by default is another matter

Note You need to log in before you can comment on or make changes to this bug.