0

I'm running an encrypted qemu virtual machine on a debian host with libvirt.

To setup the machine, I took the following steps:

  1. Place the encryption key in a file $secretfile placed in /etc/libvirt/secret
  2. Create the image: qemu-img create --object secret,id=sec0,file=$secretfile,format=raw -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 $vmfile $size
  3. Setup the VM as needed
  4. Import the VM into virt: virt-install -n $theName -r 2048 --os-type=linux --os-variant=debian9 --connect=qemu:///system --import --network=network:default --vnc --qemu-commandline="--object secret,id=sec0,file=$secretfile -drive driver=qcow2,file.filename=$vmfile,encrypt.key-secret=sec0" --disk none --cpu host --import

This worked fine with debian stretch on the host system

After upgrading to debian buster, the VM fail to start with the following

error: Failed to start domain Feigenbaum
error: internal error: process exited while connecting to monitor: 2019-07-08T11:32:00.290494Z qemu-system-x86_64: --object secret,id=sec0,file=/etc/libvirt/secret/Feigenbaum.secret: Unable to read /etc/libvirt/secret/Feigenbaum.secret: Failed to open file “/etc/libvirt/secret/Feigenbaum.secret”: Permission denied

My first guess is, that apparmor, which is new in buster, prevents access to /etc/libvirt/secret/

However, the problem persists if I set apparmor to complain mode, which in my understanding should stop blocking access to the secret file:

aa-complain /usr/sbin/libvirtd
  • I'm fairly new to apparmor: How do I make sure that apparmor is not interfering?
  • What other mechanisms could prevent access to the secret file?

-- edit --

Concerning the comment about access-rights, I think they are set correctly. It worked fine before the upgrade. Did the user running qemu-vm change with the ugprade to buster?

ls -l /etc/libvirt/secret/Feigenbaum.secret 
-rw-r----- 1 root libvirt-qemu 61 Mar  8 14:13 /etc/libvirt/secret/Feigenbaum.secret

ls -ld /etc/libvirt/secret/
drwxrwx--- 2 libvirt-qemu libvirt-qemu 102 Mar  8 14:13 /etc/libvirt/secret/

ls -ld /etc/libvirt/
drwxr-xr-x 7 root root 4096 Jul  8 11:51 /etc/libvirt/

ls -ld /etc/
drwxr-xr-x 103 root root 8192 Jul 10 06:35 /etc/

-- edit --

Reported as Bug with debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933385

  • 2
    Not ruling out apparmor but incorrect owner and too restrictive permissions are of course also a common cause of "Failed to open file : Permission denied" errors – HBruijn Jul 10 at 13:30
0

Thanks to Guido from the debian project, I was able to resolve the problem.

Apparmor does block access to the secret-File.

The qemu-commandline options are not supported and make it impossible for apparmor to set access rights correctly. This can be configured manually in /etc/apparmor.d/libvirt/TEMPLATE.qemu. The file needs be be modified from

#
# This profile is for the domain whose UUID matches this file.
#

#include <tunables/global>

profile LIBVIRT_TEMPLATE flags=(attach_disconnected) {
  #include <abstractions/libvirt-qemu>
}

to

#
# This profile is for the domain whose UUID matches this file.
#

#include <tunables/global>

profile LIBVIRT_TEMPLATE flags=(attach_disconnected) {
  #include <abstractions/libvirt-qemu>
  /etc/libvirt/secret/** r,
  /var/lib/libvirt/images/** rwk,
}

A better solution would be to use volume encryption through libvirt as documented: https://libvirt.org/formatstorageencryption.html#StorageEncryption. This should allow apparmor to set the correct access rights.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.