Bug 1732965

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