Same happens on rhel-7.5 as well.

+++ This bug was initially created as a clone of Bug #1487531 +++

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

--- Additional comment from Andrea Bolognani on 2017-09-26 14:13:15 CEST ---

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.

--- Additional comment from Andrea Bolognani on 2017-10-04 16:01:48 CEST ---

Any information about the fix, such as the git commit hash, and
when it can be expected to hit Fedora 26? :)

--- Additional comment from Lukas Vrabec on 2017-10-09 15:52:50 CEST ---

Hi Andrea, 

It should be in the next selinux-policy update. ;)

--- Additional comment from Andrea Bolognani on 2017-10-09 16:34:26 CEST ---

That's great! Looking forward to it :)

--- Additional comment from Fedora Update System on 2017-10-26 14:32:18 CEST ---

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

--- Additional comment from Fedora Update System on 2017-11-15 21:11:43 CET ---

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.

--- Additional comment from Andrea Bolognani on 2018-02-05 13:21:57 CET ---

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.

--- Additional comment from Andrea Bolognani on 2018-02-13 17:28:14 CET ---

(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. ¯\_(ツ)_/¯