Bug 959171

Summary: avc: denied { name_connect } for yppush when called from yppasswdd on NIS master
Product: Red Hat Enterprise Linux 5 Reporter: Michal Trunecka <mtruneck>
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED ERRATA QA Contact: Milos Malik <mmalik>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.9CC: andreas.luik, dwalsh, ebenes, mmalik
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: selinux-policy-2.4.6-342.el5 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 927003 Environment:
Last Closed: 2013-09-30 22:25:37 UTC Type: Bug
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: 927003    
Bug Blocks:    

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