Fedora Account System
Red Hat Associate
Red Hat Customer
When attempting to use the Virtual Machines application in Cockpit, it fails with the message, "Virtualization service (libvirt) is not active". Journal messages surrounding this event indicate it's a problem with the current SELinux policy: Nov 17 11:23:04 vmhost2.inside.msnomer.com systemd[1]: Starting setroubleshootd.service - SETroubleshoot daemon for processing new SELinux denial logs... Nov 17 11:23:04 vmhost2.inside.msnomer.com systemd[1]: Started setroubleshootd.service - SETroubleshoot daemon for processing new SELinux denial logs. Nov 17 11:23:04 vmhost2.inside.msnomer.com audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=setroubleshootd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Nov 17 11:23:04 vmhost2.inside.msnomer.com setroubleshoot[8325]: failed to retrieve rpm info for path '/run/libvirt/libvirt-sock': Nov 17 11:23:04 vmhost2.inside.msnomer.com systemd[1]: Started dbus-:1.3-org.fedoraproject.SetroubleshootPrivileged. Nov 17 11:23:04 vmhost2.inside.msnomer.com audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dbus-:1.3-org.fedoraproject.SetroubleshootPrivileged@3 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Nov 17 11:23:04 vmhost2.inside.msnomer.com setroubleshoot[8325]: SELinux is preventing pool-libvirt-db from connectto access on the unix_stream_socket /run/libvirt/libvirt-sock. For complete SELinux messages run: sealert -l 527031fe-152f-4bfe-9763-4610370a84e9 Nov 17 11:23:04 vmhost2.inside.msnomer.com setroubleshoot[8325]: SELinux is preventing pool-libvirt-db from connectto access on the unix_stream_socket /run/libvirt/libvirt-sock. ***** Plugin catchall_boolean (89.3 confidence) suggests ****************** If you want to allow daemons to enable cluster mode Then you must tell SELinux about this by enabling the 'daemons_enable_cluster_mode' boolean. Do setsebool -P daemons_enable_cluster_mode 1 ***** Plugin catchall (11.6 confidence) suggests ************************** If you believe that pool-libvirt-db should be allowed connectto access on the libvirt-sock unix_stream_socket 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 'pool-libvirt-db' --raw | audit2allow -M my-poollibvirtdb # semodule -X 300 -i my-poollibvirtdb.pp Nov 17 11:23:14 vmhost2.inside.msnomer.com systemd[1]: dbus-:1.3-org.fedoraproject.SetroubleshootPrivileged: Deactivated successfully. Nov 17 11:23:14 vmhost2.inside.msnomer.com audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dbus-:1.3-org.fedoraproject.SetroubleshootPrivileged@3 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Nov 17 11:23:15 vmhost2.inside.msnomer.com systemd[1]: setroubleshootd.service: Deactivated successfully. Nov 17 11:23:15 vmhost2.inside.msnomer.com audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=setroubleshootd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Reproducible: Always Steps to Reproduce: 1.Connect to Cockpit on the host 2.Navigate to Virtual Machines 3.Observe "Virtualization service (libvirt) is not active" message Actual Results: Virtual Machines Cockpit application doesn't start, shows error, "Virtualization service (libvirt) is not active" instead. Expected Results: Use Cockpit Virtual Machines application root@vmhost2:/sys/class/net/eno4/device# dnf list --installed | grep nux-policy selinux-policy.noarch 41.25-1.fc41 updates selinux-policy-targeted.noarch 41.25-1.fc41 updates root@vmhost2:/sys/class/net/eno4/device#
I am not an selinux maintainer, but I cannot reproduce this. Could you post the output from this after attempting to use cockpit to list virtual machines? $ sudo ausearch -i -ts boot -m avc Also, in my F41 Workstation VM, this is what I get: $ ls -lFZ /run/libvirt/libvirt-sock srw-rw-rw-. 1 root root system_u:object_r:virt_var_run_t:s0 0 Nov 17 20:37 /run/libvirt/libvirt-sock= Tested with: $ rpm -q selinux-policy cockpit cockpit-machines systemd selinux-policy-41.25-1.fc41.noarch cockpit-328-1.fc41.x86_64 cockpit-machines-323-1.fc41.noarch systemd-256.8-1.fc41.x86_64 $ uname -r 6.11.7-300.fc41.x86_64
> "Virtualization service (libvirt) is not active" There are a lot of libvirt services, but this is a short list showing how some of the services on my F41 Workstation VM are configured: $ systemctl list-unit-files -a libvirtd.\* virtqemud.\* virtstoraged.\* UNIT FILE STATE PRESET libvirtd.service disabled disabled virtqemud.service enabled enabled virtstoraged.service disabled disabled libvirtd.socket disabled disabled virtqemud.socket enabled enabled virtstoraged.socket enabled enabled 6 unit files listed.
Hello Steve, Sure: root@vmhost2:/var/lib/libvirt/images/pool_lvVMProd# ausearch -i -ts boot -m avc ---- type=AVC msg=audit(2024-11-17 13:03:30.353:958) : avc: denied { connectto } for pid=11109 comm=pool-libvirt-db path=/run/libvirt/libvirt-sock scontext=system_u:system_r:virt_dbus_t:s0 tcontext=system_u:system_r:virtd_t:s0-s0:c0.c1023 tclass=unix_stream_socket permissive=0 ---- type=AVC msg=audit(2024-11-17 13:46:20.704:2001) : avc: denied { connectto } for pid=11109 comm=pool-libvirt-db path=/run/libvirt/libvirt-sock scontext=system_u:system_r:virt_dbus_t:s0 tcontext=system_u:system_r:virtd_t:s0-s0:c0.c1023 tclass=unix_stream_socket permissive=0 ---- type=AVC msg=audit(2024-11-19 16:33:50.118:30408) : avc: denied { connectto } for pid=11109 comm=pool-libvirt-db path=/run/libvirt/libvirt-sock scontext=system_u:system_r:virt_dbus_t:s0 tcontext=system_u:system_r:virtd_t:s0-s0:c0.c1023 tclass=unix_stream_socket permissive=0 root@vmhost2:/var/lib/libvirt/images/pool_lvVMProd# ls -lFZ /run/libvirt/libvirt-sock srw-rw-rw-. 1 root root system_u:object_r:virt_var_run_t:s0 0 Nov 17 12:00 /run/libvirt/libvirt-sock= root@vmhost2:/var/lib/libvirt/images/pool_lvVMProd# rpm -q selinux-policy cockpit cockpit-machines systemd selinux-policy-41.25-1.fc41.noarch cockpit-327-1.fc41.x86_64 cockpit-machines-323-1.fc41.noarch systemd-256.8-1.fc41.x86_64 root@vmhost2:/var/lib/libvirt/images/pool_lvVMProd# systemctl list-unit-files -a libvirtd.\* virtqemud.\* virtstoraged.\* UNIT FILE STATE PRESET libvirtd.service enabled disabled virtqemud.service disabled enabled virtstoraged.service disabled disabled libvirtd.socket enabled disabled virtqemud.socket disabled enabled virtstoraged.socket disabled enabled 6 unit files listed. root@vmhost2:/var/lib/libvirt/images/pool_lvVMProd# To be clear, libvirt is working and running 10 VMs on this host with no issues. I'm able to manage them with CLI tools as well as Virtual Machine Manager. I expected the resolution of https://bugzilla.redhat.com/show_bug.cgi?id=2316474 to fix this (with the release of SELinux Policy Package 41.25-1.fc41) but it didn't, so I opened this new bug. Perhaps zpytela would be willing to have a look...
(In reply to Tony from comment #3) Try switching from the monolithic daemons to the modular daemons: https://libvirt.org/daemons.html > root@vmhost2:/var/lib/libvirt/images/pool_lvVMProd# systemctl list-unit-files -a libvirtd.\* virtqemud.\* virtstoraged.\* > UNIT FILE STATE PRESET > libvirtd.service enabled disabled ^^^^^^^------------ monolithic (disable) > virtqemud.service disabled enabled ^^^^^^^^----------- modular (enable) > virtstoraged.service disabled disabled > libvirtd.socket enabled disabled ^^^^^^^------------ monolithic (disable) > virtqemud.socket disabled enabled ^^^^^^^^----------- modular (enable) > virtstoraged.socket disabled enabled ^^^^^^^^----------- modular (enable) On an existing system, I made the switch manually with "systemctl disable" and "systemctl enable". Here is the default configuration after a clean install of F41 Workstation in a VM (Summary: STATE matches PRESET): $ systemctl list-unit-files -a virt\* libvirt\* UNIT FILE STATE PRESET libvirt-dbus.service disabled disabled libvirt-guests.service disabled disabled libvirtd.service disabled disabled virtinterfaced.service disabled disabled virtlockd.service disabled disabled virtlogd.service disabled disabled virtnetworkd.service disabled disabled virtnodedevd.service disabled disabled virtnwfilterd.service disabled disabled virtproxyd.service disabled disabled virtqemud.service enabled enabled virtsecretd.service disabled disabled virtstoraged.service disabled disabled libvirtd-admin.socket disabled disabled libvirtd-ro.socket disabled disabled libvirtd-tcp.socket disabled disabled libvirtd-tls.socket disabled disabled libvirtd.socket disabled disabled virtinterfaced-admin.socket enabled enabled virtinterfaced-ro.socket enabled enabled virtinterfaced.socket enabled enabled virtlockd-admin.socket enabled enabled virtlockd.socket enabled enabled virtlogd-admin.socket enabled enabled virtlogd.socket enabled enabled virtnetworkd-admin.socket enabled enabled virtnetworkd-ro.socket enabled enabled virtnetworkd.socket enabled enabled virtnodedevd-admin.socket enabled enabled virtnodedevd-ro.socket enabled enabled virtnodedevd.socket enabled enabled virtnwfilterd-admin.socket enabled enabled virtnwfilterd-ro.socket enabled enabled virtnwfilterd.socket enabled enabled virtproxyd-admin.socket enabled enabled virtproxyd-ro.socket enabled enabled virtproxyd-tcp.socket disabled disabled virtproxyd-tls.socket disabled disabled virtproxyd.socket enabled enabled virtqemud-admin.socket enabled enabled virtqemud-ro.socket enabled enabled virtqemud.socket enabled enabled virtsecretd-admin.socket enabled enabled virtsecretd-ro.socket enabled enabled virtsecretd.socket enabled enabled virtstoraged-admin.socket enabled enabled virtstoraged-ro.socket enabled enabled virtstoraged.socket enabled enabled virt-guest-shutdown.target static - 49 unit files listed.
Also try updating cockpit: $ sudo dnf update cockpit\* --enablerepo=updates-testing cockpit-328-1.fc41 https://bodhi.fedoraproject.org/updates/FEDORA-2024-8181f175ce
I reproduced the AVC in an F41 Workstation VM. The AVC occurs when the monolithic daemons are enabled, and the modular daemons are disabled. # auditctl -l -w /etc/shadow -p w $ sudo ausearch -i -ts 06:51:12 -m avc ---- type=PROCTITLE msg=audit(11/20/2024 06:51:12.511:397) : proctitle=/usr/sbin/libvirt-dbus --system type=PATH msg=audit(11/20/2024 06:51:12.511:397) : item=0 name=/var/run/libvirt/libvirt-sock inode=1991 dev=00:1b mode=socket,666 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:virt_var_run_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(11/20/2024 06:51:12.511:397) : cwd=/ type=SOCKADDR msg=audit(11/20/2024 06:51:12.511:397) : saddr={ saddr_fam=local path=/var/run/libvirt/libvirt-sock } type=SYSCALL msg=audit(11/20/2024 06:51:12.511:397) : arch=x86_64 syscall=connect success=no exit=EACCES(Permission denied) a0=0x7 a1=0x7f2c924e6280 a2=0x6e a3=0x7f2c800026a0 items=1 ppid=1 pid=3961 auid=unset uid=libvirtdbus gid=libvirtdbus euid=libvirtdbus suid=libvirtdbus fsuid=libvirtdbus egid=libvirtdbus sgid=libvirtdbus fsgid=libvirtdbus tty=(none) ses=unset comm=pool-libvirt-db exe=/usr/sbin/libvirt-dbus subj=system_u:system_r:virt_dbus_t:s0 key=(null) type=AVC msg=audit(11/20/2024 06:51:12.511:397) : avc: denied { connectto } for pid=3961 comm=pool-libvirt-db path=/run/libvirt/libvirt-sock scontext=system_u:system_r:virt_dbus_t:s0 tcontext=system_u:system_r:virtd_t:s0-s0:c0.c1023 tclass=unix_stream_socket permissive=0 $ systemctl list-unit-files -a libvirt\* UNIT FILE STATE PRESET libvirt-dbus.service disabled disabled libvirt-guests.service disabled disabled libvirtd.service disabled disabled libvirtd-admin.socket enabled disabled libvirtd-ro.socket enabled disabled libvirtd-tcp.socket disabled disabled libvirtd-tls.socket disabled disabled libvirtd.socket enabled disabled These are all disabled: $ systemctl list-unit-files -a virt\* I also had to disable homed, because it was triggering AVCs: $ systemctl list-unit-files -a \*homed\* UNIT FILE STATE PRESET systemd-homed-activate.service disabled enabled systemd-homed-firstboot.service disabled disabled systemd-homed.service disabled enabled Tested with: $ rpm -q selinux-policy libvirt-daemon cockpit cockpit-machines systemd selinux-policy-41.25-1.fc41.noarch libvirt-daemon-10.6.0-5.fc41.x86_64 cockpit-328-1.fc41.x86_64 cockpit-machines-323-1.fc41.noarch systemd-256.8-1.fc41.x86_64 $ uname -r 6.11.8-300.fc41.x86_64
For debugging, refresh the Cockpit VM page in the web browser and then immediately run this (some of the threads exit very quickly): $ ps -eL -o pid,ppid,tid,comm,cmd,label | egrep 'PID|libvirt' PID PPID TID COMMAND CMD LABEL 3961 1 3961 libvirt-dbus /usr/sbin/libvirt-dbus --sy system_u:system_r:virt_dbus_t:s0 3961 1 3963 pool-spawner /usr/sbin/libvirt-dbus --sy system_u:system_r:virt_dbus_t:s0 3961 1 3964 gmain /usr/sbin/libvirt-dbus --sy system_u:system_r:virt_dbus_t:s0 3961 1 3966 gdbus /usr/sbin/libvirt-dbus --sy system_u:system_r:virt_dbus_t:s0 3961 1 7746 pool-libvirt-db /usr/sbin/libvirt-dbus --sy system_u:system_r:virt_dbus_t:s0 3962 1829 3962 libvirt-dbus /usr/sbin/libvirt-dbus --se unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 3962 1829 3967 pool-spawner /usr/sbin/libvirt-dbus --se unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 3962 1829 3968 gmain /usr/sbin/libvirt-dbus --se unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 3962 1829 3970 gdbus /usr/sbin/libvirt-dbus --se unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 3962 1829 7753 pool-libvirt-db /usr/sbin/libvirt-dbus --se unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
With the monolithic daemons: $ systemctl -q list-units -a libvirt\* libvirtd.service loaded inactive dead libvirt legacy monolithic daemon libvirtd-admin.socket loaded active listening libvirt legacy monolithic daemon admin socket libvirtd-ro.socket loaded active listening libvirt legacy monolithic daemon read-only socket libvirtd.socket loaded active listening libvirt legacy monolithic daemon socket $ ls -laFZ /run/libvirt/ total 0 drwxr-xr-x. 2 root root system_u:object_r:virt_var_run_t:s0 100 Nov 20 09:05 ./ drwxr-xr-x. 58 root root system_u:object_r:var_run_t:s0 1460 Nov 20 09:05 ../ srw-------. 1 root root system_u:object_r:virt_var_run_t:s0 0 Nov 20 09:05 libvirt-admin-sock= srw-rw-rw-. 1 root root system_u:object_r:virt_var_run_t:s0 0 Nov 20 09:05 libvirt-sock= srw-rw-rw-. 1 root root system_u:object_r:virt_var_run_t:s0 0 Nov 20 09:05 libvirt-sock-ro=
This update explicitly addresses Bug 2316474: selinux-policy-41.26-1.fc41 https://bodhi.fedoraproject.org/updates/FEDORA-2024-ee068c46d3
(In reply to Steve from comment #9) > This update explicitly addresses Bug 2316474: > > selinux-policy-41.26-1.fc41 > https://bodhi.fedoraproject.org/updates/FEDORA-2024-ee068c46d3 Here is the associated upstream commit: Allow virt_dbus_t connect to virtd_t over a unix stream socket https://github.com/fedora-selinux/selinux-policy/commit/f696e058424daf5e39e2f478ae2410d0e9b0507c
(In reply to Steve from comment #9) > This update explicitly addresses Bug 2316474: > > selinux-policy-41.26-1.fc41 > https://bodhi.fedoraproject.org/updates/FEDORA-2024-ee068c46d3 Can this bz also be considered resolved?
selinux-policy-41.26-1.fc41 eliminates the AVC reported in Comment 6. For the record, no VMs need to be actually configured to test this selinux update. Tested with F41 Xfce in a VM: $ rpm -q selinux-policy libvirt-daemon libvirt-dbus cockpit cockpit-machines systemd selinux-policy-41.26-1.fc41.noarch libvirt-daemon-10.6.0-5.fc41.x86_64 libvirt-dbus-1.4.1-5.fc41.x86_64 cockpit-327-1.fc41.x86_64 cockpit-machines-323-1.fc41.noarch systemd-256.8-1.fc41.x86_64 $ uname -r 6.11.8-300.fc41.x86_64
Haven't had a chance to look at this until now. Looks like selinux-policy.noarch0-41.26-1.fc41 fixed it. Steve, thanks for those notes -- I'll test switching to the modular daemons tomorrow. Zdenek, yes this BZ can be closed. *** This bug has been marked as a duplicate of bug 2316474 ***