Comment 4 for bug 691590

Revision history for this message
Jamie Strandboge (jdstrand) wrote : Re: libvirt should not take ownership of ISO images

This whole bug is about libvirt's DAC security driver. It will chown files to the user that kvm runs as. On Ubuntu, this is the libvirt-qemu:kvm user (adjustable via /etc/libvirt/qemu.conf). If you look at the ISO file, its ownership should have been changed to this user. The DAC security driver cannot be disabled like the other security drivers (eg AppArmor and SELinux), but is instead either used alone or with one other security driver (AppArmor on Ubuntu).

I believe that if libvirt is configured to run kvm as root, then the DAC driver will not chown files (because it doesn't have to-- with DAC root can read anything). This was the case on Lucid iirc. As a workaround, you should be able to configure /etc/libvirt/qemu.conf to use:
user = "root"
group = "root"

and the problem should go away (not tested on maverick or natty libvirt). Because kvm is still confined by AppArmor in this configuration, the security stance is not greatly diminished. This was the default in Lucid.

I've not looked at how well libvirt handles chowning files, but I imagine one reason why it works the way it does is if libvirt chowned back to the user, this is a potential race condition and security issue-- ie, libvirt chowns the ISO to libvirt-qemu:kvm, then starts the machine. Now I hard link the ISO to /etc/shadow and shutdown the machine. libvirt chowns /etc/shadow to my user and group. Granted, members of the libvirtd group (ie access to qemu:///system) are considered privileged anyway (they have access to raw disks among other things), but with the above described scenario, it is far too easy to escalate privileges. Chowning to libvirt-qemu:kvm is potentially problematic as well, but the hard link to /etc/shadow is less interesting there since the user isn't libvirt-qemu and the kvm group membership doesn't gain you as much (setgid should be stripped on chgrp in Linux, and group writable files are not as common (though there are a few that are interesting)). Natty has some kernel protections that could help here, but they are upstream and upstream libvirt would not be able to rely on them being present.