Running the libvirtd on a host and defining a disk image like <disk type='file' device='disk'> <driver name='qemu' type='raw'/> <source file='/etc/shadow'/> <target dev='hdc' bus='ide'/> <address type='drive' controller='0' bus='1' unit='0'/> </disk> results in # cat /var/log/libvirt/libvirt.log 22:48:01.415: 26022: info : virSecurityDACSetOwnership:99 : Setting DAC user and group on '/etc/shadow' to '999:999' # ls -la shadow -rw------- 1 qemu qemu 1255 12. Aug 01:52 shadow A $ less -f /dev/sda in the guest gives full read/write access to the file. * Please note that this behaviour can also be triggered by a configuration of the form: <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/etc/shadow'/> <target dev='hdc' bus='ide'/> <readonly/> <address type='drive' controller='0' bus='1' unit='0'/> </disk> But it's a bit harder to actually read the file from the guest account. (Why a UID/GID change is necessary for a read-only ISO image is another question.) There should be some sort of policy preventing this and giving some sort of privilege separation between - libvirtd, running as root - the administrator (running virsh or another tool) for managing libvirtd and virtual guests - The user (in this case qemu with UID=999) under which the (qemu-kvm) guests are running. - The guest environment itself. The DAC "Security"-Feature in this case destroys the separation between the root user (of the host) and the administrator. (and root and the user under which the qemu-kvm guests are running.) Reproducible: Always
You can't prevent against bad configuration. This is the same thing as someone setting DocumentRoot / in Apache. Don't specify "disks" in your configs that aren't disks. The vulnerability would require the root user to define a disk like that and to run it from the system libvirt (again root user). If someone was using a session libvirt (running as an unprivileged user), they would not be able to even start the virtual machine to access /etc/shadow so there is only a concern here when root does something stupid by giving access to files that shouldn't have access.
Given the explanation of the maintainer we do not consider this to be a security issue. Thanks.
