Description of problem: Happens during virt-install: $ virt-install --name sid0 --os-type generic --ram 1024 --disk $PWD/sid0_disk0.qcow2 --import Starting install... ERROR internal error: qemu unexpectedly closed the monitor: 2019-07-24T20:58:36.767813Z qemu-system-x86_64: -object secret,id=masterKey0,format=raw,file=/home/christian/.config/libvirt/qemu/lib/domain-5-sid0/master-key.aes: Unable to read /home/christian/.config/libvirt/qemu/lib/domain-5-sid0/master-key.aes: Failed to open file “/home/christian/.config/libvirt/qemu/lib/domain-5-sid0/master-key.aes”: Permission denied Domain installation does not appear to have been successful. If it was, you can restart your domain by running: virsh --connect qemu:///session start sid0 otherwise, please restart your installation. SELinux is preventing qemu-system-x86 from 'open' accesses on the file /home/christian/.config/libvirt/qemu/lib/domain-1-sid0/master-key.aes. ***** Plugin restorecon (99.5 confidence) suggests ************************ If you want to fix the label. /home/christian/.config/libvirt/qemu/lib/domain-1-sid0/master-key.aes default label should be svirt_home_t. Then you can run restorecon. The access attempt may have been stopped due to insufficient permissions to access a parent directory in which case try to change the following command accordingly. Do # /sbin/restorecon -v /home/christian/.config/libvirt/qemu/lib/domain-1-sid0/master-key.aes ***** Plugin catchall (1.49 confidence) suggests ************************** If you believe that qemu-system-x86 should be allowed open access on the master-key.aes file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'qemu-system-x86' --raw | audit2allow -M my-qemusystemx86 # semodule -X 300 -i my-qemusystemx86.pp Additional Information: Source Context unconfined_u:unconfined_r:svirt_t:s0:c442,c869 Target Context system_u:object_r:ecryptfs_t:s0 Target Objects /home/christian/.config/libvirt/qemu/lib/domain-1- sid0/master-key.aes [ file ] Source qemu-system-x86 Source Path qemu-system-x86 Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.14.3-41.fc30.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 5.1.18-300.fc30.x86_64 #1 SMP Mon Jul 15 15:42:34 UTC 2019 x86_64 x86_64 Alert Count 1 First Seen 2019-07-24 13:53:11 PDT Last Seen 2019-07-24 13:53:11 PDT Local ID d0ffcf92-df79-456d-b250-bd25a67eec91 Raw Audit Messages type=AVC msg=audit(1564001591.58:34770): avc: denied { open } for pid=18194 comm="qemu-system-x86" path="/home/christian/.config/libvirt/qemu/lib/domain-1-sid0/master-key.aes" dev="ecryptfs" ino=1076705308 scontext=unconfined_u:unconfined_r:svirt_t:s0:c442,c869 tcontext=system_u:object_r:ecryptfs_t:s0 tclass=file permissive=0 Hash: qemu-system-x86,svirt_t,ecryptfs_t,file,open Version-Release number of selected component: selinux-policy-3.14.3-41.fc30.noarch Additional info: component: selinux-policy reporter: libreport-2.10.1 hashmarkername: setroubleshoot kernel: 5.1.18-300.fc30.x86_64 type: libreport
Note the suggested "restorecon" fix does not work because the "domain-1-sid0" directory may have been removed again (if it ever existed): $ ls -laZ /home/christian/.config/libvirt/qemu/lib/ total 0 drwxr-x---. 3 christian christian system_u:object_r:ecryptfs_t:s0 98 Jul 24 13:58 . drwxr-x---. 9 christian christian system_u:object_r:ecryptfs_t:s0 4096 Jul 11 22:04 .. drwxr-x---. 2 christian christian system_u:object_r:ecryptfs_t:s0 190 Jun 28 22:50 domain-13-f30 Also note that $HOME is an ecryptfs mount: $ mount | grep $HOME /home/.ecryptfs/christian/.Private on /home/christian type ecryptfs (rw,nosuid,nodev,relatime,ecryptfs_fnek_sig=...,ecryptfs_sig=...,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs)
***** Plugin restorecon (99.5 confidence) suggests ************************ If you want to fix the label. /home/christian/.config/libvirt/qemu/lib/domain-1-sid0/master-key.aes default label should be svirt_home_t. Then you can run restorecon. The access attempt may have been stopped due to insufficient permissions to access a parent directory in which case try to change the following command accordingly. Do # /sbin/restorecon -v /home/christian/.config/libvirt/qemu/lib/domain-1-sid0/master-key.aes
As mentioned above, $HOME/.config/libvirt/qemu/lib/domain-1-sid0/master-key.aes does not exist before the initial run of virt-install. The point of virt-install is to install a new VM and SELinux is preventing that. Even if the directory would exist, SELinux should not prevent legitimate programs to run. And even though .config/libvirt/qemu/lib/ is meant to have the svirt_home_t label, it's missing it and restorecon is not attempting to fix it: $ sudo semanage fcontext -l | grep .config/libvirt/qemu /home/[^/]+/\.config/libvirt/qemu(/.*)? all files unconfined_u:object_r:svirt_home_t:s0 $ restorecon -Rv /home/christian/ $ ls -1dZ {.,{,.config{,/libvirt{,/qemu{,/lib}}}}} system_u:object_r:ecryptfs_t:s0 . system_u:object_r:ecryptfs_t:s0 .config system_u:object_r:ecryptfs_t:s0 .config/libvirt system_u:object_r:ecryptfs_t:s0 .config/libvirt/qemu system_u:object_r:ecryptfs_t:s0 .config/libvirt/qemu/lib But even if restorecon would be able fix it, I'd consider it a bug that this had to be done manually. The current workaround is to disable SELinux or set it to permissive mode :-\
I see the very same issue when starting a VM in gnome-boxes.
commit 2b904103b801318c8513423f9def86180b93d1ca (HEAD -> rawhide) Author: Lukas Vrabec <lvrabec> Date: Mon Jul 29 14:42:59 2019 +0200 Allow virt_domain to Support ecryptfs home dirs. Allow virt_domain to manage ecryptfs_t objects in user home directory, if use_ecryptfs_home_dirs boolean is turned on. Resolves: rhbz#1732965
With selinux-policy-3.14.3-43.fc30, libvirt domains can be started now - thanks! However, during shutdown of a domain the following 2 alerts are printed - should I open a new bug for these? ========= monitor.sock ========= SELinux is preventing qemu-system-x86 from unlink access on the sock_file monitor.sock. Additional Information: Source Context unconfined_u:unconfined_r:svirt_t:s0:c80,c172 Target Context system_u:object_r:ecryptfs_t:s0 Target Objects monitor.sock [ sock_file ] Source qemu-system-x86 Source Path qemu-system-x86 Port <Unknown> Host horus Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.14.3-43.fc30.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name horus Platform Linux horus 5.2.5-200.fc30.x86_64 #1 SMP Wed Jul 31 14:37:17 UTC 2019 x86_64 x86_64 Alert Count 1 First Seen 2019-08-09 00:38:56 PDT Last Seen 2019-08-09 00:38:56 PDT Local ID 9be99086-d02f-40fb-b286-b103df0750ce Raw Audit Messages type=AVC msg=audit(1565336336.164:35952): avc: denied { unlink } for pid=875 comm="qemu-system-x86" name="monitor.sock" dev="ecryptfs" ino=537851890 scontext=unconfined_u:unconfined_r:svirt_t:s0:c80,c172 tcontext=system_u:object_r:ecryptfs_t:s0 tclass=sock_file permissive=0 Hash: qemu-system-x86,svirt_t,ecryptfs_t,sock_file,unlink ========= org.qemu.guest_agent.0 ========= SELinux is preventing qemu-system-x86 from unlink access on the sock_file org.qemu.guest_agent.0. Additional Information: Source Context unconfined_u:unconfined_r:svirt_t:s0:c66,c432 Target Context system_u:object_r:ecryptfs_t:s0 Target Objects org.qemu.guest_agent.0 [ sock_file ] Source qemu-system-x86 Source Path qemu-system-x86 Port <Unknown> Host horus Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.14.3-43.fc30.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name horus Platform Linux horus 5.2.5-200.fc30.x86_64 #1 SMP Wed Jul 31 14:37:17 UTC 2019 x86_64 x86_64 Alert Count 2 First Seen 2019-08-09 00:50:51 PDT Last Seen 2019-08-09 00:50:51 PDT Local ID f605d691-2245-4c34-8b9d-89e397a293dd Raw Audit Messages type=AVC msg=audit(1565337051.427:36188): avc: denied { unlink } for pid=11017 comm="qemu-system-x86" name="org.qemu.guest_agent.0" dev="ecryptfs" ino=1075736791 scontext=unconfined_u:unconfined_r:svirt_t:s0:c66,c432 tcontext=system_u:object_r:ecryptfs_t:s0 tclass=sock_file permissive=0 Hash: qemu-system-x86,svirt_t,ecryptfs_t,sock_file,unlink
FEDORA-2019-be14ea0375 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-be14ea0375
selinux-policy-3.14.3-45.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-be14ea0375
selinux-policy-3.14.3-45.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.
This bug seems to be present again in Fedora 32... I cannot start a VM via boxes with an ecryptfs home-dir while SELinux is enabled. name -srvmpio Linux 5.6.14-300.fc32.x86_64 #1 SMP Wed May 20 20:47:32 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux dnf list installed | grep boxes gnome-boxes.x86_64 3.36.3-2.fc32 @updates dnf list installed | grep "selinux-policy" selinux-policy.noarch 3.14.5-39.fc32 @updates restorecon -Rv ~/.config/libvirt/qemu ls -1dZ {.,{,.config{,/libvirt{,/qemu{,/lib}}}}} system_u:object_r:ecryptfs_t:s0 . system_u:object_r:ecryptfs_t:s0 .config system_u:object_r:ecryptfs_t:s0 .config/libvirt system_u:object_r:ecryptfs_t:s0 .config/libvirt/qemu system_u:object_r:ecryptfs_t:s0 .config/libvirt/qemu/lib sudo semanage fcontext -l | grep .config/libvirt/qemu /home/[^/]+/\.config/libvirt/qemu(/.*)? all files unconfined_u:object_r:svirt_home_t:s0
Adam, Please open a new bz and include all AVCs audited or the ausearch command output: # ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts boot