Bug 681134
Summary: | wrong nis.sh script and potential avc denial for dhclient-script and yp.conf | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Marian Ganisin <mganisin> |
Component: | ypbind | Assignee: | Honza Horak <hhorak> |
Status: | CLOSED ERRATA | QA Contact: | Jakub Prokes <jprokes> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 6.1 | CC: | atodorov, dwalsh, jpopelka, jprokes, mgrepl, psklenar, todoleza |
Target Milestone: | rc | Keywords: | Patch |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-07-22 06:46:35 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 670159 |
Description
Marian Ganisin
2011-03-01 08:25:02 UTC
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 |