Bug 959171 - avc: denied { name_connect } for yppush when called from yppasswdd on NIS master
Summary: avc: denied { name_connect } for yppush when called from yppasswdd on NIS ma...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: selinux-policy
Version: 5.9
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Miroslav Grepl
QA Contact: Milos Malik
URL:
Whiteboard:
Depends On: 927003
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-05-03 09:39 UTC by Michal Trunecka
Modified: 2014-09-30 23:34 UTC (History)
4 users (show)

Fixed In Version: selinux-policy-2.4.6-342.el5
Doc Type: Bug Fix
Doc Text:
Clone Of: 927003
Environment:
Last Closed: 2013-09-30 22:25:37 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:1312 0 normal SHIPPED_LIVE selinux-policy bug fix update 2013-09-30 21:13:27 UTC

Description Michal Trunecka 2013-05-03 09:39:46 UTC
The rules are missing on RHEL5, too.


+++ This bug was initially created as a clone of Bug #927003 +++

Description of problem:

We run RHEL 6.1 on a NIS master with two other machines running as NIS slaves.
The NIS master runs "yppasswdd --port 836".  When a NIS client changes a NIS password, the updated password is written to the passwd file, yppasswdd calls "make" in /var/yp, the local passwd.byname and passwd.byuid databases are rebuilt, but they are not pushed to the NIS slaves.  Instead the following message is logged:

kernel: type=1400 audit(1363998232.751:20728): avc:  denied  { name_connect } for  pid=9739 comm="yppush" dest=111 scontext=system_u:system_r:yppasswdd_t:s0 tcontext=system_u:object_r:portmap_port_t:s0 tclass=tcp_socket

Obviously, yppush when called from yppasswdd is not allowed to connect to the rpcbind daemon.  I have been able to "fix" this with a local SElinux rule:

allow yppasswdd_t portmap_port_t:tcp_socket name_connect;

Unfortunately, it still does not work, another avc is logged:

kernel: type=1400 audit(1364055250.719:22259): avc:  denied  { name_connect } for  pid=11586 comm="yppush" dest=804 scontext=unconfined_u:system_r:yppasswdd_t:s0 tcontext=system_u:object_r:hi_reserved_port_t:s0 tclass=tcp_socket

With a second local SElinux rule, everything works:

allow yppasswdd_t hi_reserved_port_t:tcp_socket name_connect;

Please update selinux-policy to allow yppasswdd/yppush to push NIS maps to the slaves, either with the abovementioned allows or a different approach.


Version-Release number of selected component (if applicable):

I have observed the problem with 3.7.19-93, but don't think it is fixed in the current -195.


How reproducible: always


Steps to Reproduce:
1. Set up NIS master server with at least one NIS slave, run yppasswdd daemon on NIS master.
2. Enable yppush in /var/yp/Makefile:
NOPUSH=false
3. On a NIS client, change the passwd of the user.
  
Actual results:

4. The new password is updated on the NIS master's passwd/shadow file and the database, but not on the slave server(s).  Observe abovementioned error message(s) on NIS master.

Expected results:

5. The password is also updated on the slaves, no avc error in log.

Additional info:

--- Additional comment from Miroslav Grepl on 2013-03-25 08:44:29 EDT ---

# cat mypol.te
policy_module(mypol, 1.0)

require{
 type yppasswdd_t;
}

nis_use_ypbind(yppasswdd_t)


# make -f /usr/share/selinux/devel/Makefile mypol.pp
# semodule -i mypol.pp

will fix it for now.

Comment 1 RHEL Program Management 2013-05-03 10:08:20 UTC
This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux release.  Product Management has
requested further review of this request by Red Hat Engineering, for
potential inclusion in a Red Hat Enterprise Linux release for currently
deployed products.  This request is not yet committed for inclusion in
a release.

Comment 6 errata-xmlrpc 2013-09-30 22:25:37 UTC
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.

http://rhn.redhat.com/errata/RHBA-2013-1312.html


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