Is dhclient mislabed?  

dhclient should be creating yp.conf as net_conf_t.

ls -lZ /sbin/dhclient
-rwxr-xr-x  root     root     system_u:object_r:dhcpc_exec_t   /sbin/dhclient

Dan

Nope. This is what I have:

# ls -lZ /sbin/dhclient
-rwxr-xr-x  root     root     system_u:object_r:dhcpc_exec_t   /sbin/dhclient

# rpm -V dhclient
[nothing]

But note this:

# ls -lZ *dhc*
-rw-r--r--  root     root     system_u:object_r:dhcp_etc_t     dhclient.conf
-rw-r--r--  root     root     system_u:object_r:dhcp_etc_t     dhclient-eth1.conf
-rw-r--r--  root     root     system_u:object_r:etc_runtime_t 
resolv.conf.predhclient
-rw-r--r--  root     root     system_u:object_r:net_conf_t     yp.conf.predhclient

# restorecon /etc/*dhc*

# ls -lZ *dhc*
-rw-r--r--  root     root     system_u:object_r:dhcp_etc_t     dhclient.conf
-rw-r--r--  root     root     system_u:object_r:dhcp_etc_t     dhclient-eth1.conf
-rw-r--r--  root     root     system_u:object_r:net_conf_t    
resolv.conf.predhclient
-rw-r--r--  root     root     system_u:object_r:net_conf_t     yp.conf.predhclient

When rebooting after the restorecon, the deny'ed message appear again and the
label are back to their broken state.

Looks like some transition is not happening or someone other than dhclient is
creating the file.  Is your resolv.conf created with net_conf_t?

(In reply to comment #3)
> Looks like some transition is not happening or someone other than dhclient is
> creating the file.
ifup*, Kudzu or who else is it to copy/link
/etc/sysconfig/networking/*/*/resolv.conf?


> Is your resolv.conf created with net_conf_t?

Yes, seems so:

# ls -lZ /etc/resolv.conf /etc/sysconfig/networking/*/*/resolv.conf
-rw-r--r--  root     root     system_u:object_r:net_conf_t     /etc/resolv.conf
-rw-r--r--  root     root     system_u:object_r:net_conf_t    
/etc/sysconfig/networking/profiles/default/resolv.conf
-rw-r--r--  root     root     system_u:object_r:net_conf_t    
/etc/sysconfig/networking/profiles/Local/resolv.conf
-rw-r--r--  root     root     system_u:object_r:net_conf_t    
/etc/sysconfig/networking/profiles/Standalone/resolv.conf

In this case, */Local/resolv.conf and /etc/resolv.conf are hard-linked.
# ls -li /etc/resolv.conf /etc/sysconfig/networking/*/*/resolv.conf
4694694 -rw-r--r--  2 root root 82 Jul 22 19:29 /etc/resolv.conf
 508580 -rw-r--r--  1 root root 82 Jun 20 13:58
/etc/sysconfig/networking/profiles/default/resolv.conf
4694694 -rw-r--r--  2 root root 82 Jul 22 19:29
/etc/sysconfig/networking/profiles/Local/resolv.conf
4562328 -rw-r--r--  1 root root 82 Jun 20 13:58
/etc/sysconfig/networking/profiles/Standalone/resolv.conf

Jason do you have any ideas?

Dan

FYI:

1. resolv.conf and yp.conf aren't the only files being affected:

# fixfiles check /etc
# reboot
# fixfiles check /etc
/sbin/restorecon reset /etc/X11/xorg.conf.backup-nvidia-glx context
system_u:object_r:etc_runtime_t->system_u:object_r:etc_t
/sbin/restorecon reset /etc/X11/xorg.conf context
system_u:object_r:etc_runtime_t->system_u:object_r:etc_t
/sbin/restorecon reset /etc/yp.conf context
system_u:object_r:etc_runtime_t->system_u:object_r:net_conf_t
/sbin/restorecon reset /etc/resolv.conf.predhclient context
system_u:object_r:etc_runtime_t->system_u:object_r:net_conf_t

2. I am able to reproduce this issue deterministically on one machine, but am
not able to reproduce it on 2 others with very similar configuration.

The main difference between the affected machine and the others, is the affected
machine using several networking profiles (It's my notebook), while the others
are stationary machines and only use single network profile.

With selinux-policy-targeted-1.25.2-5 in Enforcing mode on Rawhide, all of 
/etc/{resolv.conf*,yp.conf*} end up with file context 
'system_u:object_r:net_conf_t' after a dhclient session. 
dhclient does NO "restorecon"s or explicit manipulation of file contexts
anymore - it's all up to the SELinux autotrans magic to ensure that the
file contexts of files created by dhclient-script are correct . 
Other applications may write yp.conf: authconfig, 
system-config-network .
Perhaps trying this might help clarify things :
# ifdown
# ls -lZ /etc/{resolv*,yp.conf*}
# ifconfig eth0 up
# dhclient -lf /var/lib/dhcp/dhclient-eth0.leases -pf /var/run/dhclient-eth0.pid
eth0
# ls -lZ /etc/{resolv*,yp.conf*}
and append the output of the above commands to this bug report.

Created attachment 117166 [details]
As requested output of the script below


#!/bin/sh -x
ifdown eth1
ls -lZ /etc/{resolv.conf*,yp.conf*};
ifconfig eth1 up
dhclient -lf /var/lib/dhcp/dhclient-eth1.leases \
-pf /var/run/dhclient-eth1.pid
ls -lZ /etc/{resolv.conf*,yp.conf*}

Note: For reasons unknown to me (probably a bug), kudzu insists on using eth1
for the NIC.

OK, I think I see the problem now - after the ifup, the yp.conf 
files created by dhclient-script have this context:
-rw-r--r--  root     root     root:object_r:net_conf_t         /etc/yp.conf
-rw-r--r--  root     root     system_u:object_r:etc_runtime_t 
/etc/yp.conf.predhclient

During an 'ifdown', dhclient-script is run in 'STOP' mode directly by 
  /etc/sysconfig/network-scripts/ifdown-eth
NOT by dhclient, and it replaces the /etc/yp.conf written during the 'ifup'
(which does have the correct context) with /etc/yp.conf.predhclient (which
does not) and restarts the ypbind service; ypbind will then not have correct
permission for yp.conf.

So I think the "permission denied" errors occur on an ifdown, not on an
ifup - can you confirm ?

You can probably stop this problem by doing an ifdown and then a 
'restorecon /etc/yp.conf; service ypbind restart' . After the yp.conf
with correct context is in place after the DHCP interface is down, 
subsequent ifup/ifdown sequences will restore the file with the correct
context, and the problem should not re-occur.

Dan -
  Should dhclient-script be doing a 'restorecon /etc/yp.conf' in STOP mode ?
  We did decide to take all the restorecons out earlier .
  Is this caused by the fact that in STOP mode, dhclient-script is not run
  by dhclient, so does not inherit the correct context for auto-transitioning?
  If so, could we fix it by making dhclient-script get the correct context when
  run by ifdown-eth ?

No.  The problem is the yp.conf.pre* got created incorrectly at one point.

restorecon -v /etc/yp.conf*  

Should fix the problem

Dan

(In reply to comment #9)

> So I think the "permission denied" errors occur on an ifdown, not on an
> ifup - can you confirm ?

No, these appear during "service ypbind start".

(In reply to comment #10)
> No.  The problem is the yp.conf.pre* got created incorrectly at one point.
Yes, during bootup, by some of the if* scripts.
 
> restorecon -v /etc/yp.conf*  
>
> Should fix the problem
/etc/yp.conf* are being overwritten during bootup, so this doesn't help.

By whom? What? Where?

If you do a 
restorecon -v /etc/yp.conf* 
reboot
What does the /etc/yp.conf end up with for a context?

(In reply to comment #13)
> By whom? What? Where?
I wish I knew! It's dhcp-client*, if* and may-be kudzu interacting.

> If you do a 
> restorecon -v /etc/yp.conf* 
> reboot
> What does the /etc/yp.conf end up with for a context?

# ls -lZ /etc/yp.conf*
-rw-r--r--  root     root     system_u:object_r:etc_runtime_t  /etc/yp.conf
-rw-r--r--  root     root     system_u:object_r:net_conf_t    
/etc/yp.conf.predhclient
# restorecon -v /etc/yp.conf*
restorecon reset /etc/yp.conf context
system_u:object_r:etc_runtime_t->system_u:object_r:net_conf_t
# ls -lZ /etc/yp.conf*
-rw-r--r--  root     root     system_u:object_r:net_conf_t     /etc/yp.conf
-rw-r--r--  root     root     system_u:object_r:net_conf_t    
/etc/yp.conf.predhclient

# reboot
[..]
# ls -lZ /etc/yp.conf*
-rw-r--r--  root     root     system_u:object_r:etc_runtime_t  /etc/yp.conf
-rw-r--r--  root     root     system_u:object_r:net_conf_t    
/etc/yp.conf.predhclient

Fixed in selinux-policy-*-1.27.1-2.1