Bug 172374

Summary: ypxfr cannot be connected with targeted policy enforced
Product: [Fedora] Fedora Reporter: Andreas Franck <afranck>
Component: selinux-policy-targetedAssignee: Russell Coker <rcoker>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 4CC: i.mortimer
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: 14 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-11-30 14:55:26 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:

Description Andreas Franck 2005-11-03 14:24:21 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8b5) Gecko/20051006 Firefox/1.4.1

Description of problem:
The ypxfrd daemon does not work on my YP slave server when switching to policy enforced. A push of the maps from our master server results in an "RPC failure talking to server" error message.

So something seems wrong with the policy for ypserv/ypxfrd.

From the audit log:

type=AVC msg=audit(1131027296.757:398): avc:  denied  { connect } for  pid=5947 comm="ypxfr" lport=614 scontext=root:system_r:ypserv_t tcontext=root:system_r:ypserv_t tclass=tcp_socket
type=SYSCALL msg=audit(1131027296.757:398): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfb33f08 a2=25bff4 a3=bfb36248 items=0 pid=5947 auid=3006 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="ypxfr" exe="/usr/lib/yp/ypxfr"
type=SOCKADDR msg=audit(1131027296.757:398): saddr=0200006F89E23D2D0000000000000000
type=SOCKETCALL msg=audit(1131027296.757:398): nargs=3 a0=3 a1=bfb36248 a2=10





Version-Release number of selected component (if applicable):
selinux-policy-targeted-1.27.1-2.11

How reproducible:
Always

Steps to Reproduce:
Switch on the policy enforcement on a YP slave server (initialized from a master YP server with ypinit -s masterserver first.) Try to push the maps to the slave server from the master.

Additional info:

Comment 1 Andreas Franck 2005-11-03 15:06:19 UTC
The following additions to domains/misc/local.te fixed the ypxfrd problems for
me (obtained from audit2allow)

allow ypserv_t etc_t:file { getattr read };
allow ypserv_t portmap_port_t:tcp_socket name_connect;
allow ypserv_t reserved_port_t:tcp_socket name_connect;
allow ypserv_t unconfined_t:fifo_file write;
allow ypserv_t self:tcp_socket connect;
allow ypserv_t self:unix_stream_socket { connect create read write };

Although I do not know if all additions are strictly necessary.


Comment 2 Daniel Walsh 2005-11-03 18:48:58 UTC
I would prefer to make up a new policy for ypxfr.

I will experiment with this tomorrow.

Comment 3 Andreas Franck 2005-11-03 20:48:51 UTC
Fine, thank you. The additions sure were not meant as a final solution, but just
as a temporary fix. 

If you need testing of your changes (or cannot reproduce the problem), dont
hesitate to contact me.

Comment 4 Andreas Franck 2005-11-29 10:36:53 UTC
Seems the problem has been fixed with the latest update (policy version 19 now).
Thanks!

Comment 5 Ian Mortimer 2006-03-06 02:23:43 UTC
I'm still seeing this on a new FC4 install with:

   selinux-policy-targeted-1.27.1-2.22

running yppush on the master server gets this on the FC4 slave:

type=AVC msg=audit(1141612015.023:13967): avc:  denied  { create } for 
pid=11773 comm="ypxfr" scontext=root:system_r:ypserv_t
tcontext=root:system_r:ypserv_t tclass=unix_stream_socket
type=SYSCALL msg=audit(1141612015.023:13967): arch=40000003 syscall=102
success=yes exit=3 a0=1 a1=bf930ac8 a2=8cdff4 a3=ffffffe0 items=0 pid=11773
auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="ypxfr"
exe="/usr/lib/yp/ypxfr"
type=SOCKETCALL msg=audit(1141612015.023:13967): nargs=3 a0=1 a1=1 a2=0
type=AVC msg=audit(1141612015.023:13968): avc:  denied  { connect } for 
pid=11773 comm="ypxfr" scontext=root:system_r:ypserv_t
tcontext=root:system_r:ypserv_t tclass=unix_stream_socket
type=SYSCALL msg=audit(1141612015.023:13968): arch=40000003 syscall=102
success=no exit=-2 a0=3 a1=bf930ac8 a2=8cdff4 a3=8c2af9 items=0 pid=11773 auid=0
uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="ypxfr"
exe="/usr/lib/yp/ypxfr"
type=SOCKADDR msg=audit(1141612015.023:13968):
saddr=01002F7661722F72756E2F6E7363642F736F636B657400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
type=SOCKETCALL msg=audit(1141612015.023:13968): nargs=3 a0=3 a1=bf930ada a2=6e
type=AVC msg=audit(1141612015.023:13969): avc:  denied  { read } for  pid=11773
comm="ypxfr" name="nsswitch.conf" dev=md0 ino=112563
scontext=root:system_r:ypserv_t tcontext=system_u:object_r:etc_t tclass=file
type=SYSCALL msg=audit(1141612015.023:13969): arch=40000003 syscall=5
success=yes exit=3 a0=8c23f8 a1=0 a2=1b6 a3=9f1b410 items=1 pid=11773 auid=0
uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="ypxfr"
exe="/usr/lib/yp/ypxfr"
type=CWD msg=audit(1141612015.023:13969):  cwd="/var/yp"
type=PATH msg=audit(1141612015.023:13969): item=0 name="/etc/nsswitch.conf"
flags=101  inode=112563 dev=09:00 mode=0100644 ouid=0 ogid=0 rdev=00:00
type=AVC msg=audit(1141612015.023:13970): avc:  denied  { getattr } for 
pid=11773 comm="ypxfr" name="nsswitch.conf" dev=md0 ino=112563
scontext=root:system_r:ypserv_t tcontext=system_u:object_r:etc_t tclass=file
type=SYSCALL msg=audit(1141612015.023:13970): arch=40000003 syscall=197
success=yes exit=0 a0=3 a1=bf930c68 a2=8cdff4 a3=3 items=0 pid=11773 auid=0
uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="ypxfr"
exe="/usr/lib/yp/ypxfr"type=AVC_PATH msg=audit(1141612015.023:13970): 
path="/etc/nsswitch.conf"


and the transfer fails.  (After `setenforce 0' it works which shows the NIS
configuration is correct).