Bug 1732965 - SELinux is preventing qemu-system-x86 from 'open' accesses on the file /home/christian/.config/libvirt/qemu/lib/domain-1-sid0/master-key.aes.
Summary: SELinux is preventing qemu-system-x86 from 'open' accesses on the file /home/...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 30
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Lukas Vrabec
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:8a3d921c021c93cb2c8eac40b68...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-07-24 20:59 UTC by Christian Kujau
Modified: 2019-09-06 12:33 UTC (History)
6 users (show)

Fixed In Version: selinux-policy-3.14.3-45.fc30
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-09-06 12:33:44 UTC


Attachments (Terms of Use)

Description Christian Kujau 2019-07-24 20:59:47 UTC
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

Comment 1 Christian Kujau 2019-07-24 21:04:18 UTC
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)

Comment 2 Lukas Vrabec 2019-07-25 15:12:00 UTC
*****  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

Comment 3 Christian Kujau 2019-07-28 08:56:44 UTC
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 :-\

Comment 4 Valentin Rothberg 2019-07-28 09:21:52 UTC
I see the very same issue when starting a VM in gnome-boxes.

Comment 5 Lukas Vrabec 2019-07-29 12:45:39 UTC
commit 2b904103b801318c8513423f9def86180b93d1ca (HEAD -> rawhide)
Author: Lukas Vrabec <lvrabec@redhat.com>
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

Comment 6 Christian Kujau 2019-08-09 07:56:34 UTC
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

Comment 7 Fedora Update System 2019-09-05 06:52:10 UTC
FEDORA-2019-be14ea0375 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-be14ea0375

Comment 8 Fedora Update System 2019-09-05 12:53:08 UTC
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

Comment 9 Fedora Update System 2019-09-06 12:33:44 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.