Description of problem:
After updating packages (via PackageKit), I discovered that /var/run/nm-dns-dnsmasq.conf lost its proper selinux context, type NetworkManager_var_run_t.  It was instead reverted to var_run_t, and when NetworkManager next tried to change the network status, it failed to replace that file.

I previously ran into this, reported on bug #708701 comment #5, but didn't know how it got borked at that time.

Unfortunately this time it looks like auditd wasn't running (or even enabled, probably a failing of systemd upgrades).  But I had a systemtap script collecting setxattr calls, and I see during the middle of a yum transaction that restorecon changed this file.  That yum transaction included selinux policies.

Version-Release number of selected component (if applicable):
    Updated     selinux-policy-3.10.0-51.fc16.noarch           ?
    Update                     3.10.0-55.fc16.noarch           @updates
    Updated     selinux-policy-targeted-3.10.0-51.fc16.noarch  ?
    Update                              3.10.0-55.fc16.noarch  @updates

How reproducible:
Unknown

Steps to Reproduce:
1. Set dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf
2. Update selinux-policy*
3. Change network connectivity
  
Actual results:
NM can't write the file, so falls back to simple resolv.conf dns.

Expected results:
NM makes whatever change it needs and keeps resolv.conf pointing to localhost dnsmasq.  So nm-dns-dnsmasq.conf should be NetworkManager_var_run_t.

Additional info:
Running restorecon manually on that file does set var_run_t.  There's a path that does restorecon -R /var/run in the selinux-policy-targeted postinstall, which seems the likely culprit here.