1

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

DoRe
  • 41
  • 5
  • 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 '19 at 13:30

1 Answers1

1

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.

DoRe
  • 41
  • 5