Bug 681134 - wrong nis.sh script and potential avc denial for dhclient-script and yp.conf
wrong nis.sh script and potential avc denial for dhclient-script and yp.conf
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: ypbind (Show other bugs)
6.1
Unspecified Unspecified
medium Severity medium
: rc
: ---
Assigned To: Honza Horak
Jakub Prokes
: Patch
Depends On:
Blocks: 670159
  Show dependency treegraph
 
Reported: 2011-03-01 03:25 EST by Marian Ganisin
Modified: 2015-07-22 02:46 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-07-22 02:46:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Marian Ganisin 2011-03-01 03:25:02 EST
Description of problem:
It looks like /etc/yp.conf has wrong context (from point of view of dhclient), I see following avc messages during testing:

type=1400 audit(1298964229.456:4): avc:  denied  { rename } for  pid=1154 comm="mv" name="yp.conf" dev=sdb1 ino=6293160 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:etc_runtime_t:s0 tclass=file
type=1400 audit(1298964229.605:5): avc:  denied  { write } for  pid=1108 comm="dhclient-script" name="yp.conf" dev=sdb1 ino=6293160 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:etc_runtime_t:s0 tclass=file
type=1400 audit(1298964229.627:6): avc:  denied  { write } for  pid=1108 comm="dhclient-script" name="yp.conf" dev=sdb1 ino=6293160 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:etc_runtime_t:s0 tclass=file
type=1400 audit(1298964229.649:7): avc:  denied  { append } for  pid=1108 comm="dhclient-script" name="yp.conf" dev=sdb1 ino=6293160 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:etc_runtime_t:s0 tclass=file
type=1400 audit(1298964229.671:8): avc:  denied  { append } for  pid=1108 comm="dhclient-script" name="yp.conf" dev=sdb1 ino=6293160 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:etc_runtime_t:s0 tclass=file

Version-Release number of selected component (if applicable):
selinux-policy-3.7.19-73.el6.noarch
selinux-policy-targeted-3.7.19-73.el6.noarch

yp.conf belongs to ypbind-1.20.4-29.el6.i686
dhclient-script belongs to dhclient-4.1.1-16.P1.el6.i686


Additional info:
I can't evaluate impact, I can't decide if dhclient-script should have access to yp.conf, I just see the denials.
Comment 1 Miroslav Grepl 2011-03-01 07:38:25 EST
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/
Comment 2 Marian Ganisin 2011-03-01 09:01:14 EST
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
Comment 3 Daniel Walsh 2011-03-01 09:43:39 EST
Maybe dhclient init scripts created with the wrong context on boot and then failed to relabel it?
Comment 4 Jiri Popelka 2011-03-01 11:23:31 EST
(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 ?
Comment 5 Jiri Popelka 2011-03-01 11:36:19 EST
(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.
Comment 7 RHEL Product and Program Management 2011-03-02 16:57:52 EST
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.
Comment 10 RHEL Product and Program Management 2011-07-05 21:15:05 EDT
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.
Comment 14 Honza Horak 2012-07-18 09:37:31 EDT
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
Comment 15 Honza Horak 2012-07-18 09:45:15 EDT
(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.
Comment 16 Honza Horak 2012-07-20 06:35:33 EDT
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.
Comment 17 RHEL Product and Program Management 2013-10-13 21:09:23 EDT
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.
Comment 23 errata-xmlrpc 2015-07-22 02:46:35 EDT
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

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