Bug 245157 - selinux interecepts named
selinux interecepts named
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-21 08:32 EDT by Adam Tkac
Modified: 2013-04-30 19:36 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-09-11 10:48:42 EDT
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 Adam Tkac 2007-06-21 08:32:45 EDT
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 09:44:17 EDT
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 09:50:21 EDT
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 12:18:35 EDT
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 12:26:51 EDT
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 04:06:31 EDT
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 06:55:36 EDT
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 10:51:53 EDT
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 11:11:39 EDT
Fixed in selinux-policy-3.0.1-6
Comment 9 Adam Tkac 2007-07-03 16:34:47 EDT
Works fine, thanks

Adam
Comment 10 Adam Tkac 2007-09-05 10:33:42 EDT
Same problems with selinux-policy-3.0.7-2.fc8 . Reopening
Comment 11 Daniel Walsh 2007-09-10 13:12:49 EDT
selinux-policy-3.0.7-8.fc8
Comment 12 Adam Tkac 2007-09-11 10:48:42 EDT
Thanks

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