Description of problem: This happens when starting a virtual machine with 3D acceleration enabled. SELinux is preventing qemu-system-x86 from 'search' accesses on the directory dev. ***** Plugin qemu_file_image (98.8 confidence) suggests ******************* If dev is a virtualization target Then you need to change the label on dev' Do # semanage fcontext -a -t virt_image_t 'dev' # restorecon -v 'dev' ***** Plugin catchall (2.13 confidence) suggests ************************** If you believe that qemu-system-x86 should be allowed search access on the dev directory 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 system_u:system_r:svirt_t:s0:c35,c566 Target Context system_u:object_r:sysctl_dev_t:s0 Target Objects dev [ dir ] Source qemu-system-x86 Source Path qemu-system-x86 Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-37.12-2.fc37.noarch Local Policy RPM selinux-policy-targeted-37.12-2.fc37.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 5.19.14-300.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Oct 5 21:31:43 UTC 2022 x86_64 x86_64 Alert Count 1 First Seen 2022-10-11 15:27:02 CEST Last Seen 2022-10-11 15:27:02 CEST Local ID 16196454-1046-4153-b048-fcba302c947f Raw Audit Messages type=AVC msg=audit(1665494822.997:1054): avc: denied { search } for pid=62767 comm="qemu-system-x86" name="dev" dev="proc" ino=1751 scontext=system_u:system_r:svirt_t:s0:c35,c566 tcontext=system_u:object_r:sysctl_dev_t:s0 tclass=dir permissive=0 Hash: qemu-system-x86,svirt_t,sysctl_dev_t,dir,search Version-Release number of selected component: selinux-policy-targeted-37.12-2.fc37.noarch Additional info: component: selinux-policy reporter: libreport-2.17.4 hashmarkername: setroubleshoot kernel: 5.19.14-300.fc37.x86_64 type: libreport Potential duplicate: bug 1928612
Kamile, Could you please try if the following module is sufficient? # cat local_virt_sysctl.cil (allow virt_domain sysctl_dev_t (dir (getattr open search))) # semodule -i local_virt_sysctl.cil After gathering the data: # semodule -r local_virt_sysctl.cil Perhaps these permissions will be required, too: (allow virt_domain sysctl_dev_t (file (getattr ioctl lock open read))) I cannot reproduce it, is the video model "virtio"?
(In reply to Zdenek Pytela from comment #1) > # cat local_virt_sysctl.cil > (allow virt_domain sysctl_dev_t (dir (getattr open search))) > # semodule -i local_virt_sysctl.cil When I do this, I no longer see this error: říj 13 14:57:14 hydra audit[55974]: AVC avc: denied { search } for pid=55974 comm="qemu-system-x86" name="dev" dev="proc" ino=35866 scontext=system_u:system_r:svirt_t:s0:c143,c348 tcontext=system_u:object_r:sysctl_dev_t:s0 tclass=dir permissive=0 but instead I see this new one: říj 13 14:59:00 hydra audit[56548]: AVC avc: denied { getattr } for pid=56548 comm="qemu-system-x86" path="/proc/sys/dev/i915/perf_stream_paranoid" dev="proc" ino=35868 scontext=system_u:system_r:svirt_t:s0:c25,c164 tcontext=system_u:object_r:sysctl_dev_t:s0 tclass=file permissive=0 And also these lines: říj 13 14:59:03 hydra audit[56622]: AVC avc: denied { search } for pid=56622 comm="setroubleshootd" name="dev" dev="proc" ino=35866 scontext=system_u:system_r:setroubleshootd_t:s0 tcontext=system_u:object_r:sysctl_dev_t:s0 tclass=dir permissive=0 říj 13 14:59:05 hydra sedispatch[1254]: AVC Message regarding setroubleshoot, ignoring message > Perhaps these permissions will be required, too: > (allow virt_domain sysctl_dev_t (file (getattr ioctl lock open read))) If I add this to the cil file, I no longer see any of the error messages described above. So this particular problem seems "fixed". (I still get bug 2127175 and bug 2122918 on each VM start, though). > After gathering the data: > # semodule -r local_virt_sysctl.cil $ sudo semodule -r local_virt_sysctl.cil libsemanage.semanage_direct_remove_key: Unable to remove module local_virt_sysctl.cil at priority 400. (No such file or directory). semodule: Failed! Fortunately I figured out that the ".cil" suffix shouldn't be there, so I'm fine :-) But the error is really confusing. > I cannot reproduce it, is the video model "virtio"? Yes, I have a default libvirt VM created in virt-manager, I just enabled "3D acceleration" at Video Virtio and enabled "OpenGL" at Display Spice. Then boot my F37 (KDE) system.
Kamile, thank you for all the troubleshooting, we have a PR now. https://github.com/fedora-selinux/selinux-policy/pull/1442 Checks -> Details -> Artifacts -> rpms (In reply to Kamil Páral from comment #2) ... > > Perhaps these permissions will be required, too: > > (allow virt_domain sysctl_dev_t (file (getattr ioctl lock open read))) > > If I add this to the cil file, I no longer see any of the error messages > described above. So this particular problem seems "fixed". (I still get bug > 2127175 and bug 2122918 on each VM start, though). The first one needs a boolean turned on, the other is under investigation. > > After gathering the data: > > # semodule -r local_virt_sysctl.cil > > $ sudo semodule -r local_virt_sysctl.cil > libsemanage.semanage_direct_remove_key: Unable to remove module > local_virt_sysctl.cil at priority 400. (No such file or directory). > semodule: Failed! > > Fortunately I figured out that the ".cil" suffix shouldn't be there, so I'm > fine :-) But the error is really confusing. Right, sorry for the typo. > > I cannot reproduce it, is the video model "virtio"? > > Yes, I have a default libvirt VM created in virt-manager, I just enabled "3D > acceleration" at Video Virtio and enabled "OpenGL" at Display Spice. Then > boot my F37 (KDE) system. ...and expected connection: none then I see it as well.
FEDORA-2022-f7fdf02056 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-f7fdf02056
FEDORA-2022-f7fdf02056 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-f7fdf02056` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-f7fdf02056 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-f7fdf02056 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.