Bug 172374 - ypxfr cannot be connected with targeted policy enforced
ypxfr cannot be connected with targeted policy enforced
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Russell Coker
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-03 09:24 EST by Andreas Franck
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: 14
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-11-30 09:55:26 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Andreas Franck 2005-11-03 09:24:21 EST
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 10:06:19 EST
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 13:48:58 EST
I would prefer to make up a new policy for ypxfr.

I will experiment with this tomorrow.
Comment 3 Andreas Franck 2005-11-03 15:48:51 EST
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 05:36:53 EST
Seems the problem has been fixed with the latest update (policy version 19 now).
Thanks!
Comment 5 Ian Mortimer 2006-03-05 21:23:43 EST
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).


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