[libvirt] libvirt chowning my kernel/initrd files

[Seth Jennings]

On Wed, May 16, 2012 at 2:31 PM, Eric Blake <eblake at redhat.com> wrote:
> On 05/16/2012 11:19 AM, Seth Jennings wrote:
>> On Wed, May 16, 2012 at 12:06 PM, Eric Blake <eblake at redhat.com> wrote:
>>> On 05/16/2012 10:30 AM, Seth Jennings wrote:
> Did you mean for this replay to go to the list?

Yes I did :-/  Back on the list.

> You might also want to play with dynamic_ownership in
> /etc/libvirt/qemu.conf, which changes whether libvirtd will chown in the
> first place.

That does the trick.  Although, without dynamic_ownership,
libvirt-qemu doesn't have write access to the LV I'm using as a virtio
disk.  So I guess it's a two edged sword.  However, manually adding
the  libvirt-qemu user to the disk group fixed that.  Might be a
little coarse security-wise, but I don't feel like writing new udev
rules for the device mapper today.

<snip>
> At least read access is required, for the uid that qemu will be running
> as.  If the file permissions _already_ grants read access, and libvirt
> isn't recognizing that fact but doing the chown anyways, then that would
> be something worth cleaning up.

That is the case; it is chowning things even if it has the access
required.  Additionally, at least in Ubuntu 12.04, it does _not_
restore the original ownership.  The initial chown when the VM starts
is to libvirt-qemu:kvm, and once the VM shuts down, the ownership
switches to root:root, regardless of the original ownership.

Honestly, this could be used for privilege escalation of sorts.  If I
was a member of the libvirtd group, I could target a file owned by
another user by making it the kernel for a VM and starting it.  Of
course, the VM wouldn't boot (unless the target file was actually a
kernel image), but I would have successfully chowned that file to
root:root using libvirtd, which runs a root, to do it.  The user that
originally owned the file would no longer be the owner.

Thanks,
Seth