Description of problem:
I am frequently getting selinux alerts that /etc/ld.so.cache is unable to be accessed by system processes. Examination of the logs seems to point to auditd running at the same time it occurs. I run restorecon -v /etc/ld.so.cache and the file is relabelled to the correct context 'system_u:object_r:ld_so_cache_t:s0' but I have to do this every hour or so (seems to be some builtin systemd timer or cron job or something)

Version-Release number of selected component (if applicable):
selinux-policy-targeted.noarch-3.13.1-283.28.fc27
audit.x86_64 2.8.3-1.fc27

How reproducible:
very

Steps to Reproduce:
1. run fedora for a few hours, wait for the selinux alerts

Actual results:
file relabelled

Expected results:
file not relabelled

Additional info:
This bug may be more applicable to the audit component than selinux, but I am not fully sure that auditd is what is doing it although it does show the selinux alerts in the audit.log as well...