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: 2020-06-08 11:17 UTC (History)
7 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
Type: ---


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.

Comment 10 Adam 2020-06-07 21:20:01 UTC
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

Comment 11 Zdenek Pytela 2020-06-08 11:17:00 UTC
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


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