Bug 644808 - NetworkManager writing out resolv.conf with wrong context
Summary: NetworkManager writing out resolv.conf with wrong context
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy
Version: 6.0
Hardware: All
OS: Linux
high
medium
Target Milestone: rc
: ---
Assignee: Miroslav Grepl
QA Contact: Milos Malik
URL:
Whiteboard:
Depends On: 639074
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-10-20 11:22 UTC by RHEL Program Management
Modified: 2012-10-15 13:51 UTC (History)
5 users (show)

Fixed In Version: selinux-policy-3.7.19-54.el6_0.2
Doc Type: Bug Fix
Doc Text:
With SELinux running in the enforcing mode, resuming the system from the Suspend mode resulted in the /etc/resolv.conf file being recreated with the wrong security context. This meant that under subsequent normal operation Network manager was unable to update the /etc/resolv.conf file. This was caused by NetworkManager, which was running under wrong SELinux domain, "devicekit_power_t". With this update, the proper SELinux domain transition from DeviceKit-power to NetworkManager has been added, and resuming from the Suspend mode now works as expected.
Clone Of:
Environment:
Last Closed: 2010-11-10 19:01:39 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2010:0845 normal SHIPPED_LIVE selinux-policy bug fix update 2010-11-09 17:05:17 UTC

Description RHEL Program Management 2010-10-20 11:22:04 UTC
This bug has been copied from bug #639074 and has been proposed
to be backported to 6.0 z-stream (EUS).

Comment 3 Miroslav Grepl 2010-10-20 13:41:19 UTC
Fixed in selinux-policy-3.7.19-54.el6_0.2.

Comment 5 Jaromir Hradilek 2010-10-21 08:53:53 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
With SELinux running in the enforcing mode, resuming the system from the Suspend mode failed, because the /etc/resolv.conf file did not have the correct security context. This was caused by NetworkManager, which was running under wrong SELinux domain, "devicekit_power_t". With this update, the proper SELinux domain transition from DeviceKit-power to NetworkManager has been added, and resuming from the Suspend mode now works as expected.

Comment 6 Mark Chappell 2010-10-21 10:44:31 UTC
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1 +1 @@
-With SELinux running in the enforcing mode, resuming the system from the Suspend mode failed, because the /etc/resolv.conf file did not have the correct security context. This was caused by NetworkManager, which was running under wrong SELinux domain, "devicekit_power_t". With this update, the proper SELinux domain transition from DeviceKit-power to NetworkManager has been added, and resuming from the Suspend mode now works as expected.+With SELinux running in the enforcing mode, resuming the system from the Suspend mode resulted in the /etc/resolv.conf file being recreated with the wrong security context. This meant that under subsequent normal operation Network manager was unable to update the /etc/resolv.conf file.  This was caused by NetworkManager, which was running under wrong SELinux domain, "devicekit_power_t".  With this update, the proper SELinux domain transition from DeviceKit-power to NetworkManager has been added, and resuming from the Suspend mode now works as expected.

Comment 9 errata-xmlrpc 2010-11-10 19:01:39 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2010-0845.html


Note You need to log in before you can comment on or make changes to this bug.