Yes, this is a bad label. 

But the question is, how did it get mislabeled.  Since it is labeled
etc_runtime_t, this means some init script must have created /etc/yp.conf with
the wrong label originally.

Any idea? 

What the following grep shows for you

# grep -r yp.conf /etc/init.d/

No direct update of yp.conf in /etc/init.d

Surprisingly, content of yp.conf is genetated by dhclient-script:

# cat /etc/yp.conf 
# generated by /sbin/dhclient-script
domain redhat.com server 172.16.52.225

Both network and NetworkManager services are on. I am just guessing, children of network init script don't change domain and keep etc_runtime_t, then NetworkManager performs correct transition and tries to reconfigure network  with reported denials as a result. (strange enough, I would expect NM doesn't touch configured device, I didn't verify this behaviour).

Finally, restorecon did proper corrective action:

# restorecon -nv /etc/yp.conf 
restorecon reset /etc/yp.conf context system_u:object_r:etc_runtime_t:s0->system_u:object_r:net_conf_t:s0

Maybe dhclient init scripts created with the wrong context on boot and then failed to relabel it?

(In reply to comment #2)
> Surprisingly, content of yp.conf is genetated by dhclient-script:
> 
> # cat /etc/yp.conf 
> # generated by /sbin/dhclient-script
> domain redhat.com server 172.16.52.225

Must have been generated by client side configuration script
/etc/dhcp/dhclient.d/nis.sh (ypbind package).

It is a helper script to handle NIS options for dhclient-script.

But it seems that it correctly runs restorecon
on the newly created /etc/yp.conf

Are you able to reproduce the problem, Marian ?

(In reply to comment #4)
> But it seems that it correctly runs restorecon
> on the newly created /etc/yp.conf
Actually it is not. I was looking at Fedora.
See also bug #593278.

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

How to reproduce:
1) create a kickstart script, which enables nis using authconfig, for example as follows:
authconfig --enablemd5 --enableshadow --enablenis --nisdomain example.com --nisserver nis.example.com
2) install system using this kickstart script
3) observe context of /etc/yp.conf on the installed system

(In reply to comment #14)
> How to reproduce:
> 1) create a kickstart script, which enables nis using authconfig, for
> example as follows:
> authconfig --enablemd5 --enableshadow --enablenis --nisdomain example.com
> --nisserver nis.example.com
> 2) install system using this kickstart script
> 3) observe context of /etc/yp.conf on the installed system

Actually, this is not a full reproducer, it is only a method how /etc/yp.conf with wrong context could be created.

For reproducing we can run dhclient script manually with setting up a new NIS domain and let servers empty to use broadcast using:
# new_nis_domain=newnis.example.com /etc/NetworkManager/dispatcher.d/10-dhclient eth0 up

We need to use new domain or specify different servers set to trigger yp.conf saving/restoring ability in /etc/dhcp/dhclient.d/nis.sh

What is odd, I actually don't see any AVC issues. 

On the other hand, I see maybe even more significant issue - restoring config file doesn't work. When we run for example:

# new_nis_domain=newnis.example.com /etc/NetworkManager/dispatcher.d/10-dhclient eth0 up
# /etc/NetworkManager/dispatcher.d/10-dhclient eth0 down

..the later command should restore the saved config file (done by the first command), while it should be restored only if a saved file at /var/lib/dhclient is found.

However, nis.sh script defines CONF=/etc/yp.conf and then searches /var/lib/dhclient/${CONF}.predhclient.eth0, which expands to /var/lib/dhclient//etc/yp.conf.predhclient.eth0, which is obviously wrong and it need to be fixed. 

Using a patch from comment #12 fixes this issue and would fix even potential AVC issues, since it works fine in Fedora for long time.

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-1332.html