This doesn't seem to occur with F14:
dhclient-4.2.0-6.fc14.x86_64
initscripts-9.20-1.fc14.x86_64
selinux-policy-3.9.5-3.fc14.noarch
selinux-policy-targeted-3.9.5-3.fc14.noarch

After suspending and resuming:
$ ls -Z /var/run/dhclient-eth0.pid 
-rw-r--r--. root root system_u:object_r:dhcpc_var_run_t:s0 /var/run/dhclient-eth0.pid

We are not seeing this from others.  If you run restorecon -R -v /var/run and suspend/resume does it come back?  It could be something mislabeled causing this.

(In reply to comment #2)
> We are not seeing this from others.  If you run restorecon -R -v /var/run and
> suspend/resume does it come back?  It could be something mislabeled causing
> this.

[stephent@walnut run]$ sudo restorecon -R -v /var/run
[stephent@walnut run]$ fixfiles check *.pid
# suspend/resume here
[stephent@walnut run]$ fixfiles check *.pid
/sbin/restorecon reset /var/run/dhclient-eth0.pid context system_u:object_r:var_run_t:s0->system_u:object_r:dhcpc_var_run_t:s0

I will do a full relabel and report back ...

Same thing after a full relabel:

[stephent@walnut run]$ fixfiles check *.pid
# suspend/resume here
[stephent@walnut run]$ fixfiles check *.pid
/sbin/restorecon reset /var/run/dhclient-eth0.pid context system_u:object_r:var_run_t:s0->system_u:object_r:dhcpc_var_run_t:s0
[stephent@walnut run]$ 

Forgot to report:
pm-utils-1.2.6.1-1.fc13.x86_64

I see nothing different in policy around this from F13 to F14.  I guess the question is what process is creating the /var/run/dhclient-eth0.pid file, and why aren't others seeing this.  

Miroslav can you see if you can reproduce this?

Depends on how I suspend:

1. suspend from gnome menu: System->Shut Down->Suspend
   dhclient-eth0.pid is mislabeled after resume

2. suspend with:
   sudo sh -c 'echo -n mem > /sys/power/state'
   dhclient-eth0.pid is correctly labeled after resume

[stephent@walnut run]$ sudo restorecon -R -v /var/run
[stephent@walnut run]$ sudo sh -c 'echo -n mem > /sys/power/state'
[stephent@walnut run]$ sudo restorecon -R -v /var/run
[stephent@walnut run]$ 
[stephent@walnut run]$ 
[stephent@walnut run]$ sudo restorecon -R -v /var/run
# suspend from gnome menu here
[stephent@walnut run]$ sudo restorecon -R -v /var/run
restorecon reset /var/run/dhclient-eth0.pid context system_u:object_r:var_run_t:s0->system_u:object_r:dhcpc_var_run_t:s0
[stephent@walnut run]$

Created attachment 449906 [details]
pm-suspend-1.log

/var/log/pm-suspend.log after suspending from the gnome menu and resuming.

The file is not changed if suspending is done with:
sudo sh -c 'echo -n mem > /sys/power/state'

In addition to removing the NetworkManager package and enabling the network
service, I have a slightly modified ifcfg-eth0.

[stephent@walnut network-scripts]$ rpm -qa 'Net*'
NetworkManager-glib-0.8.1-6.git20100831.fc13.x86_64
[stephent@walnut network-scripts]$ chkconfig --list network
network         0:off 1:off 2:on 3:on 4:on 5:on 6:off
[stephent@walnut network-scripts]$ cat
/etc/sysconfig/network-scripts/ifcfg-eth0 
# Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet
controller
DEVICE=eth0
BOOTPROTO=dhcp
HWADDR=00:30:67:36:C5:AF
ONBOOT=yes
TYPE=Ethernet
NM_CONTROLLED=no
USERCTL=yes
PEERDNS=yes
IPV6INIT=no
DHCP_HOSTNAME=`hostname`
DHCPRELEASE=y
[stephent@walnut network-scripts]$

I have twice now reproduced the mislabeling of dhclient-eth0.pid after clean F13 installs, one onto a spare disk partition and one in a VM. Both were F13 x86_64 installs from DVD followed with enabling of networking, updating, removing NetworkManager, and enabling the network service.

The reproducer is this /etc/sysconfig/network-scripts/ifcfg-eth0
(here with the VM's MAC address):

# Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller
DEVICE=eth0
BOOTPROTO=dhcp
HWADDR=52:54:00:12:34:56
ONBOOT=yes
TYPE=Ethernet
NM_CONTROLLED=no
USERCTL=yes
PEERDNS=yes
IPV6INIT=no
#DHCP_HOSTNAME=`hostname`
#DHCPRELEASE=y

The mislabeling does not occur with
the version of /etc/sysconfig/network-scripts/ifcfg-eth0
that was created during the install and subsequent enabling of networking:

# Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+
DEVICE=eth0
ONBOOT=yes
HWADDR=52:54:00:12:34:56
TYPE=Ethernet
BOOTPROTO=dhcp
DEFROUTE=yes
PEERDNS=yes
PEERROUTES=yes
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
NAME="System eth0"
UUID=5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03

Adding Dan back to the CC list, since I now have a reproducer after a clean F13 install (comment 9).

Found the diff on the first try. :-)

Commenting out this line in the reproducer ifcfg-eth0 restores correct labeling of dhclient-eth0.pid after resuming:

NM_CONTROLLED=no

Verified in a VM.

NB: In a VM, suspending fails and is immediately followed by a resume.

(In reply to comment #11)
... 
> Commenting out this line in the reproducer ifcfg-eth0 restores correct labeling
> of dhclient-eth0.pid after resuming:
> 
> NM_CONTROLLED=no
...

"NM_CONTROLLED=no" is added by system-config-network-gui.

In a test, I deleted all net devices with system-config-network-gui and added a new device. The resulting ifcfg-eth0 reproduces this bug:

[stephent@walnut network-scripts]$ cat ifcfg-eth0 
# Please read /usr/share/doc/initscripts-*/sysconfig.txt
# for the documentation of these parameters.
DEVICE=eth0
BOOTPROTO=dhcp
TYPE=Ethernet
HWADDR=00:30:67:36:c5:af
NM_CONTROLLED=no
ONBOOT=yes
USERCTL=yes
PEERDNS=yes
IPV6INIT=no

NM_CONTROLLED is not documented in /usr/share/doc/initscripts-*/sysconfig.txt.

(In reply to comment #5)
> I guess the question is what process is creating the /var/run/dhclient-eth0.pid file, and
> why aren't others seeing this.
The pid file is created by dhclient itself (initscripts and NM only tell dhclient the path and name).
There was nothing changed in pid file handling between f13 and f14.
dhclient creates the file like this:
pfdesc = open (path_dhclient_pid, O_CREAT | O_TRUNC | O_WRONLY | O_CLOEXEC, 0644);
pf = fdopen (pfdesc, "we");

(In reply to comment #12)
> NM_CONTROLLED is not documented in /usr/share/doc/initscripts-*/sysconfig.txt.
'NM_CONTROLLED=no' makes the specific device identified in the HWADDR field
of the ifcfg file ignored by NetworkManager.


There's a pm-utils script 
/usr/lib[64]/pm-utils/sleep.d/56dhclient
shipped with dhclient for handling suspend/hibernate.

This script downs (ifdown-eth) any dhclient-controlled interfaces that are not already
controlled by NetworkManager. The ifdown-eth also removes the pid file.
On resume, 56dhclient brings up (ifup-eth) only those
interfaces that were downed for the suspend/hibernate operation.
ifup-eth starts again dhclient which creates the pid file.

We can restore the pid file context when the interface is brought up after suspend
  while read device ; do
      /sbin/ifup ${device}
+      [ -x /sbin/restorecon ] && /sbin/restorecon /var/run/dhclient-${device}.pid >/dev/null 2>&1
  done < ${PM_DHCLIENT_SUSPEND}
but that only hides the bug somewhere else.

I can reproduce that with System->Shutdown->Hibernate.
When I check (ls -lZ) the context of the pid file in 56dhclient after it brings up the interface I
see that the the context is incorrect (var_run_t instead of dhcpc_var_run_t).
However when I run the 56dhclient by hand (./56dhclient hibernate; ./56dhclient thaw)
the created pid has correct context.

If dhclient is run it should be transitioning to dhcpc_t which would do the right thing.  But what is the context of the tool that is running ./56dhclient hibernate; ./56dhclient  when the machine comes back up.

Miroslav does F13 have

sysnet_domtrans_dhcpc(devicekit_power_t)

This transition is missing.

(Copied from Bug 568575, which is against F12. This adds an avc denial reproducer, but no new info, IIUC.)

I do not have NetworkManager installed, yet my selinux avc denial report hashed
to this bug. My configuration is as described in Bug 637583. To reproduce these
denials:

1. sudo restorecon -R -v /var/run
2. System->Shutdown->Suspend then resume
3. system-control-network
4. Deactivate
5. Activate
Results: SELinux security alert appears immediately

Interestly, dhclient-eth0.pid has the correct label when I check it after this:
[stephent@walnut run]$ sudo restorecon -R -n -v /var/run
[stephent@walnut run]$ ls -Z dhclient-eth0.pid 
-rw-r--r--. root root unconfined_u:object_r:dhcpc_var_run_t:s0
dhclient-eth0.pid

[stephent@walnut ~]$ rpm -qa 'Net*' 'selinux*' 'pm*' 'dhc*' initscripts | sort
dhclient-4.1.1-23.P1.fc13.x86_64
initscripts-9.12.1-1.fc13.x86_64
NetworkManager-glib-0.8.1-6.git20100831.fc13.x86_64
pm-utils-1.2.6.1-1.fc13.x86_64
selinux-policy-3.7.19-57.fc13.noarch
selinux-policy-targeted-3.7.19-57.fc13.noarch

[stephent@walnut ~]$ sudo ausearch -m avc -ts 11:02:10
----
time->Sat Oct  2 11:02:10 2010
type=SYSCALL msg=audit(1286042530.503:106): arch=c000003e syscall=2 success=no
exit=-13 a0=7fff9f17ef28 a1=80000 a2=1b6 a3=0 items=0 ppid=19277 pid=19324
auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1
comm="dhclient" exe="/sbin/dhclient"
subj=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1286042530.503:106): avc:  denied  { read } for  pid=19324
comm="dhclient" name="dhclient-eth0.pid" dev=dm-2 ino=489
scontext=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023
tcontext=system_u:object_r:var_run_t:s0 tclass=file
----
time->Sat Oct  2 11:02:10 2010
type=SYSCALL msg=audit(1286042530.505:107): arch=c000003e syscall=2 success=no
exit=-13 a0=1d06520 a1=80000 a2=1b6 a3=0 items=0 ppid=19277 pid=19324 auid=500
uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1
comm="dhclient" exe="/sbin/dhclient"
subj=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1286042530.505:107): avc:  denied  { read } for  pid=19324
comm="dhclient" name="dhclient-eth0.pid" dev=dm-2 ino=489
scontext=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023
tcontext=system_u:object_r:var_run_t:s0 tclass=file
----
time->Sat Oct  2 11:02:10 2010
type=SYSCALL msg=audit(1286042530.505:108): arch=c000003e syscall=2 success=no
exit=-13 a0=7fff9f17ef28 a1=80241 a2=1a4 a3=0 items=0 ppid=19277 pid=19324
auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1
comm="dhclient" exe="/sbin/dhclient"
subj=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1286042530.505:108): avc:  denied  { write } for  pid=19324
comm="dhclient" name="dhclient-eth0.pid" dev=dm-2 ino=489
scontext=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023
tcontext=system_u:object_r:var_run_t:s0 tclass=file
[stephent@walnut ~]$

Fixed in selinux-policy-3.7.19-64.fc13

selinux-policy-3.7.19-65.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/selinux-policy-3.7.19-65.fc13

selinux-policy-3.7.19-65.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update selinux-policy'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/selinux-policy-3.7.19-65.fc13

selinux-policy-3.7.19-65.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.