I don't think this is related to Tuned. As far as I can see, Tuned doesn't use grep anywere to check the contents of /etc/modprobe.d/tuned.conf. And even if it did, the scontext=system_u:system_r:iptables_t:s0 indicates grep was not run from Tuned. But to make sure your grep is not mislabeled, please post the output of the following:
ls -lZ /usr/bin/grep

Please tell us how you got this SELinux denial. How can we reproduce it? Thanks.

I get exactly the same issue and have done for a while on versions 7.2, then 7.3 and now 7.4 of RHEL.

The Type of the relevant files is as follows:

# ls -lZ /etc/modprobe.d/tuned.conf
-rw-r--r--. root root system_u:object_r:modules_conf_t:s0 /etc/modprobe.d/tuned.conf

# ls -lZ /usr/bin/grep
-rwxr-xr-x. root root system_u:object_r:bin_t:s0       /usr/bin/grep


There doesn't seem to be any specific steps to reproduce this, I get it when I do the following:

1) Build a RHEL 7.4 box
2) Make sure that tuned is installed
3) Make SELinux policy is set to enforcing
4) Log in and await your SELinux error

Note that I've only had the chance to see this on client builds as these are the only ones I've been looking at for quite some time.

This is probably also not tuned so should be probably be redirected to some other component

(In reply to Mark Crossland from comment #3)
> I get exactly the same issue and have done for a while on versions 7.2, then
> 7.3 and now 7.4 of RHEL.
> 
> The Type of the relevant files is as follows:
> 
> # ls -lZ /etc/modprobe.d/tuned.conf
> -rw-r--r--. root root system_u:object_r:modules_conf_t:s0
> /etc/modprobe.d/tuned.conf
> 
> # ls -lZ /usr/bin/grep
> -rwxr-xr-x. root root system_u:object_r:bin_t:s0       /usr/bin/grep
> 

Both SELinux labels seems good. I think this is not Tuned bug, but maybe selinux-policy bug. From the SELinux policy I have found that there is at least (maybe there are more) /usr/libexec/iptables/iptables.init script which has the iptables_exec_t context which changes to iptables_t and the iptables.init script contains the folowing lines:

210:	&& grep -qIsE "^install[[:space:]]+${_IPV}[[:space:]]+/bin/(true|false)" /etc/modprobe.conf /etc/modprobe.d/* ; then
377:	&& grep -qIsE "^install[[:space:]]+${_IPV}[[:space:]]+/bin/(true|false)" /etc/modprobe.conf /etc/modprobe.d/* ; then

I.e. it's probably running 'grep' with the iptables_t context over the files from the /etc/modprobe.d which have the modules_conf_t label. So I think it's OK and it should be allowed by the SELinux policy. So reassigning to the selinux-policy for further investigation.

comment permissions

[root@router ~]# ls -lZ /usr/bin/grep
-rwxr-xr-x. root root system_u:object_r:bin_t:s0       /usr/bin/grep
[root@router ~]#

As to reproducing the error, curiously the auditd logs are empty, but the message appeared in /var/log/messages when running

)
Nov 21 17:31:01 router setroubleshoot: SELinux is preventing /usr/bin/grep from read access on the file /etc/modprobe.d/lockd.conf. For complete SELinux messages run: sealert -l 8f8426fb-329d-4786-872c-69ef36e9020d
Nov 21 17:31:01 router python: SELinux is preventing /usr/bin/grep from read access on the file /etc/modprobe.d/lockd.conf.#012#012*****  Plugin catchall (100. confidence) suggests   **************************#012#012If you believe that grep should be allowed read access on the lockd.conf file by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'grep' --raw | audit2allow -M my-grep#012# semodule -i my-grep.pp#012
Nov 21 17:31:02 router setroubleshoot: SELinux is preventing /usr/bin/grep from read access on the file /etc/modprobe.d/mlx4.conf. For complete SELinux messages run: sealert -l 8f8426fb-329d-4786-872c-69ef36e9020d
Nov 21 17:31:02 router python: SELinux is preventing /usr/bin/grep from read access on the file /etc/modprobe.d/mlx4.conf.#012#012*****  Plugin catchall (100. confidence) suggests   **************************#012#012If you believe that grep should be allowed read access on the mlx4.conf file by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'grep' --raw | audit2allow -M my-grep#012# semodule -i my-grep.pp#012
Nov 21 17:31:02 router setroubleshoot: SELinux is preventing /usr/bin/grep from read access on the file /etc/modprobe.d/truescale.conf. For complete SELinux messages run: sealert -l 8f8426fb-329d-4786-872c-69ef36e9020d
Nov 21 17:31:02 router python: SELinux is preventing /usr/bin/grep from read access on the file /etc/modprobe.d/truescale.conf.#012#012*****  Plugin catchall (100. confidence) suggests   **************************#012#012If you believe that grep should be allowed read access on the truescale.conf file by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'grep' --raw | audit2allow -M my-grep#012# semodule -i my-grep.pp#012
Nov 21 17:31:02 router setroubleshoot: SELinux is preventing /usr/bin/grep from read access on the file /etc/modprobe.d/tuned.conf. For complete SELinux messages run: sealert -l 8f8426fb-329d-4786-872c-69ef36e9020d
Nov 21 17:31:02 router python: SELinux is preventing /usr/bin/grep from read access on the file /etc/modprobe.d/tuned.conf.#012#012*****  Plugin catchall (100. confidence) suggests   **************************#012#012If you believe that grep should be allowed read access on the tuned.conf file by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'grep' --raw | audit2allow -M my-grep#012# semodule -i my-grep.pp#012

possibly iptables, which is called asynchronously by fail2ban when a probe occurs

But I also see a few _systemd_ provoked messages

[root@router ~]# grep -i avc /var/log/audit/audit*
/var/log/audit/audit.log.1:type=USER_AVC msg=audit(1511189901.727:107483): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  received policyload notice (seqno=8)  exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
/var/log/audit/audit.log.1:type=AVC msg=audit(1511303458.010:5578): avc:  denied  { read } for  pid=20931 comm="grep" name="lockd.conf" dev="dm-1" ino=203043361 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:modules_conf_t:s0 tclass=file
/var/log/audit/audit.log.1:type=AVC msg=audit(1511303458.010:5579): avc:  denied  { read } for  pid=20931 comm="grep" name="mlx4.conf" dev="dm-1" ino=203219880 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:modules_conf_t:s0 tclass=file
/var/log/audit/audit.log.1:type=AVC msg=audit(1511303458.010:5580): avc:  denied  { read } for  pid=20931 comm="grep" name="truescale.conf" dev="dm-1" ino=202693206 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:modules_conf_t:s0 tclass=file
/var/log/audit/audit.log.1:type=AVC msg=audit(1511303458.010:5581): avc:  denied  { read } for  pid=20931 comm="grep" name="tuned.conf" dev="dm-1" ino=202693174 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:modules_conf_t:s0 tclass=file
/var/log/audit/audit.log.2:type=USER_AVC msg=audit(1510680601.626:76782): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  received policyload notice (seqno=7)  exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
/var/log/audit/audit.log.3:type=USER_AVC msg=audit(1510679401.506:76717): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  received policyload notice (seqno=6)  exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'

/var/log/audit/audit.log.4:type=USER_AVC msg=audit(1510679318.861:76697): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  received policyload notice (seqno=5)  exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
[root@router ~]#

I believe this bug is a duplicate of BZ#1438937. The fact that you see the denials is caused by old (RHEL-7.4.z) policy version installed on your machines.

(In reply to Milos Malik from comment #7)
> I believe this bug is a duplicate of BZ#1438937. The fact that you see the
> denials is caused by old (RHEL-7.4.z) policy version installed on your
> machines.

"You are not authorized to access bug #1438937.

Most likely the bug has been restricted for internal development processes and we cannot grant access."

Are you able to let us know whether and when BZ#1438937 is going to be fixed?

Comment #7 
mmalik
I am unaware of any issued update later than what I run.  Where might I obtain this package?

Assumedly Comment #8
lvrabec

The bug is not visible with my rights, usually kept concealed because of PII of a customer -- seemingly not so here -- please add me to its CC list so I might view it

This bug will be fixed as soon as RHEL-7.5 goes out. The fix is present in selinux-policy >= 3.13.1-174.el7.

R P Herrold, 

Milos is right, Fix will be part RHEL-7.5. Closing as NEXTRELEASE.