Bug 245157

Summary: selinux interecepts named
Product: [Fedora] Fedora Reporter: Adam Tkac <atkac>
Component: selinux-policyAssignee: Daniel Walsh <dwalsh>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: rawhideCC: ovasik, quentin, tmraz
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-09-11 14:48:42 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 Adam Tkac 2007-06-21 12:32:45 UTC
Description of problem:
I've updated named (BIND) to latest upstream (9.5.0a5) yesterday and now I'm not
able start it. System relabel doesn't help. Message from denial:

type=AVC msg=audit(1182427576.557:56): avc:  denied  { name_bind } for  pid=8904
comm="named" src=28892 scontext=root:system_r:named_t:s0
tcontext=system_u:object_r:port_t:s0 tclass=udp_socket


Version-Release number of selected component (if applicable):
rpm -q selinux-policy
selinux-policy-2.6.5-2.fc8
rpm -q bind
bind-9.5.0a5-1.fc8

How reproducible:
always

Comment 1 Daniel Walsh 2007-06-21 13:44:17 UTC
So named now listens on udp to port 28892?

If yes you can add this port to dns by executing

semanage port -a -t dns_port_t -P udp 28892

If this is accurate I will update the change in policy

Comment 2 Adam Tkac 2007-06-21 13:50:21 UTC
Hm, wait. I've done some tests and looks that named want listens on random udp
port (I'm really unsure why). Let me check it

Comment 3 Adam Tkac 2007-06-21 16:18:35 UTC
Hm, I digging around this and I've found where problem is. When named initscript
(/etc/init.d/named) has context system_u:object_r:initrc_exec_t named can't
start. When I set context to root:object_r:etc_t all works fine. Also when I
tried this simple script

#/bin/bash
/usr/sbin/named -u named
echo $?

with system_u:object_r:initrc_exec_t context named can't start. I'm not sure
where problem is...

Adam

Comment 4 Daniel Walsh 2007-06-21 16:26:51 UTC
That is because named does not transition from unconfined_t when not run from
initrc_exec_t.  So this does not fix the problem.  

The question is, what/why is named listening on random udp ports?  Who connects
to those ports?  Also you are not using nis?

Comment 5 Adam Tkac 2007-06-22 08:06:31 UTC
This is new function in BIND

2129.   [func]          Provide a pool of UDP sockets for queries to be
                        made over. See use-queryport-pool, queryport-pool-ports
                        and queryport-pool-updateinterval.

So named could bind random UPD sockets now... It's possible specify ranges but I
think that selinux could let named bind to anything socket

Adam

Comment 6 Daniel Walsh 2007-06-25 10:55:36 UTC
So is there a default pool?  Or does it just pick these randomly?  Who connects
to these ports and how do they find out about them?

Comment 7 Adam Tkac 2007-06-28 14:51:53 UTC
Ports are picked randomly and are used when named doesn't know answer and must
query other server. For example named bind() 8 random sockets and send queries
to other servers through them. After while delete sockets and bind() another
eight. Previous BIND created socket for each query but didn't bind() it (one
query, one created socket => bind() isn't needed). Current BIND tries improve
answer performance so it create some sockets and bind() it so SELinux deny it.
bind() is needed because you want use ports with same number for 2 minutes (for
example)

Adam

Comment 8 Daniel Walsh 2007-07-02 15:11:39 UTC
Fixed in selinux-policy-3.0.1-6


Comment 9 Adam Tkac 2007-07-03 20:34:47 UTC
Works fine, thanks

Adam

Comment 10 Adam Tkac 2007-09-05 14:33:42 UTC
Same problems with selinux-policy-3.0.7-2.fc8 . Reopening

Comment 11 Daniel Walsh 2007-09-10 17:12:49 UTC
selinux-policy-3.0.7-8.fc8

Comment 12 Adam Tkac 2007-09-11 14:48:42 UTC
Thanks