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.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/691590

Title:
  libvirt should not take ownership of ISO images

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to