Description of problem: SELinux is preventing systemd-machine from 'create' accesses on the sock_file io.systemd.Machine. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that systemd-machine should be allowed create access on the io.systemd.Machine sock_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 'systemd-machine' --raw | audit2allow -M my-systemdmachine # semodule -X 300 -i my-systemdmachine.pp Additional Information: Source Context system_u:system_r:systemd_machined_t:s0 Target Context system_u:object_r:systemd_userdbd_runtime_t:s0 Target Objects io.systemd.Machine [ sock_file ] Source systemd-machine Source Path systemd-machine Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-3.14.6-20.fc33.noarch Local Policy RPM selinux-policy-targeted-3.14.6-20.fc33.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name (removed) Platform Linux (removed) 5.8.0-0.rc7.1.fc33.x86_64 #1 SMP Thu Jul 30 18:24:26 UTC 2020 x86_64 x86_64 Alert Count 1 First Seen 2020-08-01 14:59:40 +05 Last Seen 2020-08-01 14:59:40 +05 Local ID f9ee66a7-c891-487c-ace1-60c5bbdab303 Raw Audit Messages type=AVC msg=audit(1596275980.755:122): avc: denied { create } for pid=1143 comm="systemd-machine" name="io.systemd.Machine" scontext=system_u:system_r:systemd_machined_t:s0 tcontext=system_u:object_r:systemd_userdbd_runtime_t:s0 tclass=sock_file permissive=1 Hash: systemd-machine,systemd_machined_t,systemd_userdbd_runtime_t,sock_file,create Version-Release number of selected component: selinux-policy-targeted-3.14.6-20.fc33.noarch Additional info: component: selinux-policy reporter: libreport-2.13.1 hashmarkername: setroubleshoot kernel: 5.8.0-0.rc7.1.fc33.x86_64 type: libreport
I think this - and related denials also for io.systemd.Machine, e.g.: time->Thu Aug 6 14:53:51 2020 type=AVC msg=audit(1596750831.021:20522): avc: denied { connectto } for pid=1152 comm="polkitd" path="/run/systemd/userdb/io.systemd.Machine" scontext=system_u:system_r:policykit_t:s0 tcontext=system_u:system_r:systemd_machined_t:s0 tclass=unix_stream_socket permissive=1 ---- time->Thu Aug 6 14:53:51 2020 type=AVC msg=audit(1596750831.029:20534): avc: denied { connectto } for pid=101147 comm="pkla-check-auth" path="/run/systemd/userdb/io.systemd.Machine" scontext=system_u:system_r:policykit_auth_t:s0 tcontext=system_u:system_r:systemd_machined_t:s0 tclass=unix_stream_socket permissive=1 , are preventing libvirt virtual machines from running and also breaking the systemd-machined service on boot: https://openqa.fedoraproject.org/tests/636429#step/base_services_start/15 The former would violate Beta criterion "The release must be able host virtual guest instances of the same release" and the latter would violate Final criterion "All system services present after installation with one of the release-blocking package sets must start properly, unless they require hardware which is not present", so proposing as a Beta blocker with fallback to Final. :)
*** Bug 1862687 has been marked as a duplicate of this bug. ***
*** Bug 1862688 has been marked as a duplicate of this bug. ***
Shouldn't the tracker depend on this bug, rather than vice versa?
I can reproduce this: virt-manager client pops a dialog that says: Error starting domain: Remote peer disconnected host journal says: Aug 10 11:05:07 fmac.local systemd-machined[1851]: Failed to bind to varlink socket: Permission denied Aug 10 11:05:07 fmac.local audit[1851]: AVC avc: denied { write } for pid=1851 comm="systemd-machine" name="userdb" dev="tmpfs" ino=18772 scontext=system_u:system_r:systemd_machined_t:s0 tcontext=system_u:object_r:systemd_userdbd_runtime_t:s0 tclass=dir permissive=0 Aug 10 11:05:07 fmac.local systemd-machined[1851]: Failed to fully start up daemon: Permission denied Aug 10 11:05:07 fmac.local systemd[1]: Started Virtual Machine and Container Registration Service. Aug 10 11:05:07 fmac.local audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-machined comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Aug 10 11:05:07 fmac.local libvirtd[830]: Remote peer disconnected Aug 10 11:05:07 fmac.local systemd[1]: systemd-machined.service: Main process exited, code=exited, status=1/FAILURE Aug 10 11:05:07 fmac.local systemd[1]: systemd-machined.service: Failed with result 'exit-code'.
systemd-246-1.fc33.x86_64 selinux-policy-3.14.6-21.fc33.noarch
Discussed during the 2020-08-10 blocker review meeting: [0] The decision to delay the classification of this bug as an "AcceptedBlocker" (Beta) and to classify this bug as an "AcceptedBlocker" (Final) was made as it violates the following Final criterion: "All system services present after installation with one of the release-blocking package sets must start properly..." We're less sure about whether it breaks virtualization, so we will delay the decision on Beta blocker status to look into that some more. [0] https://meetbot.fedoraproject.org/fedora-blocker-review/2020-08-10/f33-blocker-review.2020-08-10-16.17.txt
Discussed during the 2020-08-10 blocker review meeting: [0] The decision to classify this bug as an "AcceptedBlocker" (Beta) was made as it violates the following Beta criterion: "The release must be able host virtual guest instances of the same release" Since both adamw and cmurf have reported being unable to launch VMs with SELinux in enforcing mode, this overrides earlier acceptance as a Final blocker. [0] https://meetbot.fedoraproject.org/fedora-blocker-review/2020-08-10/f33-blocker-review.2020-08-10-16.17.txt
I've submitted a Fedora PR to address the issue as reported in this bz and its direct duplicates: https://github.com/fedora-selinux/selinux-policy/pull/405 For denials in c#1, I will continue in another bug.
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle. Changing version to 33.
Given the pull request merged, I suppose this bz should be in POST.
(In reply to Geoffrey Marr from comment #8) > The decision to classify this bug as an "AcceptedBlocker" (Beta) was made Geoff, you forgot to update the whiteboard, doing that now.
Resolved by this commit: commit d4a034518393bd1c0277a4dd3e87c8e94b394317 Author: Zdenek Pytela <zpytela> Date: Tue Aug 11 12:47:42 2020 +0200 Allow systemd-machined create userdbd runtime sock files Create the systemd_create_userdbd_runtime_sock_files() interface. Resolves: rhbz#1862686
So this is now in selinux-policy-3.14.6-24.fc33 which is in recent composes. Setting ON_QA. openQA base_services_start is now passing on Rawhide, so the systemd-machined service bug is fixed now. We should check the virtual machine start issue is fixed too before closing this.
VM start bug seems to be resolved for me too. Closing.