Bug 245157 - selinux interecepts named
Summary: selinux interecepts named
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Fedora Extras Quality Assurance
Keywords: Reopened
Depends On:
TreeView+ depends on / blocked
Reported: 2007-06-21 12:32 UTC by Adam Tkac
Modified: 2013-04-30 23:36 UTC (History)
3 users (show)

Clone Of:
Last Closed: 2007-09-11 14:48:42 UTC

Attachments (Terms of Use)

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
rpm -q bind

How reproducible:

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

/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...


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


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


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


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

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

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