Description of problem: After installing libvirt-nss and adding libvirt under 'hosts' in nsswitch.conf, whenever the system is started and user logs in, the user is given an alert about AVC denial. So far openvpn, cupsd and chronyd have been found to try the same action (search) on /var/lib/libvirt Hashes from SETroubleshoot for all the events: - openvpn,openvpn_t,virt_var_lib_t,dir,search - cupsd,cupsd_t,virt_var_lib_t,dir,search - chronyd,chronyd_t,virt_var_lib_t,dir,search Normal operation and use of the OS after login doesn't seem to cause any additional alerts. SELinux is preventing chronyd from 'search' accesses on the directory /var/lib/libvirt. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that chronyd should be allowed search access on the libvirt 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 'chronyd' --raw | audit2allow -M my-chronyd # semodule -X 300 -i my-chronyd.pp Additional Information: Source Context system_u:system_r:chronyd_t:s0 Target Context system_u:object_r:virt_var_lib_t:s0 Target Objects /var/lib/libvirt [ dir ] Source chronyd Source Path chronyd Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages Policy RPM <Unknown> Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 4.12.8-300.fc26.x86_64 #1 SMP Thu Aug 17 15:30:20 UTC 2017 x86_64 x86_64 Alert Count 2 First Seen 2017-09-01 10:34:19 EEST Last Seen 2017-09-01 10:34:47 EEST Local ID 4466f1b7-a0ee-4aa2-b79d-126737e790fb Raw Audit Messages type=AVC msg=audit(1504251287.320:273): avc: denied { search } for pid=1149 comm="chronyd" name="libvirt" dev="dm-1" ino=3145909 scontext=system_u:system_r:chronyd_t:s0 tcontext=system_u:object_r:virt_var_lib_t:s0 tclass=dir permissive=0 Hash: chronyd,chronyd_t,virt_var_lib_t,dir,search Additional info: component: selinux-policy reporter: libreport-2.9.1 hashmarkername: setroubleshoot kernel: 4.12.8-300.fc26.x86_64 type: libreport
I'm hitting the same issue, and hopefully I can provide some insights on what's needed to make it go away. Permissions on the /var/lib/libvirt directory are way too strict: drwxr-xr-x. 8 root root system_u:object_r:virt_var_lib_t:s0 4096 Aug 4 22:17 /var/lib/libvirt The only direct children of the directory are a bunch more directories with static names, so there's no point in preventing anyone from listing them; using the same label as the parent, var_lib_t, should be just fine. Among the contents of the /var/lib/libvirt/dnsmasq directory, the libvirt NSS plugin is only interested in: *.status *.macs which contain the information needed to perform name resolution. This information is, I believe, not security-sensitive, given that any user on the host can already retrieve the IP address of any running guest through a read-only, unprivileged libvirt connection: $ sudo -u nobody virsh -r -c qemu:///system domifaddr guest Name MAC address Protocol Address ------------------------------------------------------------------------------- vnet0 52:54:00:e9:0a:e1 ipv4 192.168.124.111/24 I don't see a reason why any process shouldn't be allowed to read those files, but if anyone actually does I guess we could have a SELinux boolean controlling it, and instruct users to flip it at the same time as they're modifying /etc/nsswitch.conf to enable the libvirt NSS plugin, making it completely opt-in.
Any information about the fix, such as the git commit hash, and when it can be expected to hit Fedora 26? :)
Hi Andrea, It should be in the next selinux-policy update. ;)
That's great! Looking forward to it :)
selinux-policy-3.13.1-260.14.fc26 has been pushed to the Fedora 26 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-2017-d312739a4e
selinux-policy-3.13.1-260.14.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
A very similar error started popping up again on my laptop today: SELinux is preventing chronyd from read access on the directory /var/lib/libvirt/dnsmasq. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that chronyd should be allowed read access on the dnsmasq 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 'chronyd' --raw | audit2allow -M my-chronyd # semodule -X 300 -i my-chronyd.pp Additional Information: Source Context system_u:system_r:chronyd_t:s0 Target Context system_u:object_r:virt_var_lib_t:s0 Target Objects /var/lib/libvirt/dnsmasq [ dir ] Source chronyd Source Path chronyd Port <Unknown> Host [REDACTED] Source RPM Packages Target RPM Packages libvirt-daemon-driver-network-3.7.0-3.fc27.x86_64 Policy RPM selinux-policy-3.13.1-283.21.fc27.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name [REDACTED] Platform Linux [REDACTED] 4.14.16-300.fc27.x86_64 #1 SMP Wed Jan 31 19:24:27 UTC 2018 x86_64 x86_64 Alert Count 2 First Seen 2018-02-05 11:26:20 CET Last Seen 2018-02-05 11:26:20 CET Local ID 1dfa3d72-41fb-4cd8-9c67-a30302073872 Raw Audit Messages type=AVC msg=audit(1517826380.865:640): avc: denied { read } for pid=8336 comm="chronyd" name="dnsmasq" dev="dm-1" ino=143037 scontext=system_u:system_r:chronyd_t:s0 tcontext=system_u:object_r:virt_var_lib_t:s0 tclass=dir permissive=0 Hash: chronyd,chronyd_t,virt_var_lib_t,dir,read So it's read on /var/lib/libvirt/dnsmasq/ rather than search on /var/lib/libvirt/ this time. Looks very much related. I couldn't spot any obvious difference in selinux-policy between the last known working version and the newest one. Rolling back didn't help. I spent the morning trying to root cause but at this point I'm basically at my wits' end. It can be reproduced by simply installing libvirt and libvirt-nss in a freshly-provisioned Fedora 27 system.
(In reply to Andrea Bolognani from comment #7) > A very similar error started popping up again on my laptop today: [...] > It can be reproduced by simply installing libvirt and libvirt-nss > in a freshly-provisioned Fedora 27 system. Aaaaand now it doesn't reproduce anymore, either on my laptop or in a fresh guest. ¯\_(ツ)_/¯