Bug 998682

Summary: SELinux denial when starting rabbitmq-server service
Product: [Fedora] Fedora Reporter: James Slagle <jslagle>
Component: rabbitmq-serverAssignee: Peter Lemenkov <lemenkov>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: flavio, hbrock, hubert.plociniczak, jeckersb, lemenkov, lnie, mrunge, pavel.nedr, rjones, scottt.tw, skottler
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: rabbitmq-server-3.1.5-4.fc20 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-04-14 22:38:12 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1032595    
Attachments:
Description Flags
Use ephemeral port for probing none

Description James Slagle 2013-08-19 18:51:50 UTC
Description of problem:

Can not start rabbitmq-server service due to an SELinux denial.

Version-Release number of selected component (if applicable):
[root@dublin ~]# rpm -q rabbitmq-server selinux-policy-targeted
rabbitmq-server-3.1.3-1.fc19.noarch
selinux-policy-targeted-3.12.1-69.fc19.noarch


How reproducible:
Every time

Steps to Reproduce:
1. Install Fedora 19
2. Apply all updates
3. yum install rabbitmq-server
4. systemctl start rabbitmq-server

Actual results:
service never starts, /var/log/audit/audit.log shows:
type=AVC msg=audit(1376938176.987:37273): avc:  denied  { name_bind } for  pid=65250 comm="beam.smp" src=10441 scontext=system_u:system_r:rabbitmq_beam_t:s0 tcontext=system_u:object_r:unreserved_port_t:s0 tclass=tcp_socket


Expected results:
service starts successfully

Additional info:
Disabling SELinux temporarily makes it so that rabbitmq-server can start:
[root@dublin ~]# setenforce 0
[root@dublin ~]# systemctl restart rabbitmq-server.service 
[root@dublin ~]# systemctl status rabbitmq-server.service 
rabbitmq-server.service - RabbitMQ broker
   Loaded: loaded (/usr/lib/systemd/system/rabbitmq-server.service; enabled)
   Active: active (running) since Mon 2013-08-19 14:51:05 EDT; 1s ago

Comment 1 John Eckersberg 2014-01-24 15:50:22 UTC
Created attachment 855059 [details]
Use ephemeral port for probing

This patch fixes the AVC denials.  For details, see:

https://bugzilla.redhat.com/show_bug.cgi?id=1032595#c8

Comment 2 Scott Tsai 2014-03-17 15:41:00 UTC
@Peter,

I've ran into this bug as well and independently verified John's analysis:

rabbitmq-server is trying to detect whether the host supports IPv6 by listening on TCP ports starting from 10000. Incrementing the port number by 1 if the port is in use or EPERM. See the ipv6_status function and FIRST_TEST_BIND_PORT in rabbit_networking.erl (https://github.com/rabbitmq/rabbitmq-server/blob/b47325e38b578b8e629baaeb2ab04040b273634f/src/rabbit_networking.erl#L42).

John's patch at https://bugzilla.redhat.com/attachment.cgi?id=855059 patches FIRST_TEST_BIND_PORT to be 32768 and the existing ephemeral_port_t SELinux rules would allow the name_bind. Could you merge this patch?

The actual experiment I did:

$ kill -USR1 $(pgrep ^auditd) # rotate audit.log
$ /usr/bin/time systemctl restart rabbitmq-server.service
/usr/bin/time systemctl restart rabbitmq-server.service 
0.00user 0.00system 0:04.59elapsed 0%CPU (0avgtext+0avgdata 1400maxresident)k
0inputs+0outputs (0major+779minor)pagefaults 0swaps

$ grep 'name_bind.* src=[[:digit:]]*' /var/log/audit/audit.log | wc -l
8581

Inspecting audit.log, I see the last name_bind denied was 18580, which implies that the first successful listen is on 18581/tcp which is amqp_port_t. Running in permissive mode reduces the startup time:

$ setenforce 0
$ /usr/bin/time systemctl restart rabbitmq-server.service 
0.00user 0.00system 0:01.44elapsed 0%CPU (0avgtext+0avgdata 1404maxresident)k
0inputs+0outputs (0major+778minor)pagefaults 0swaps
$ grep 'name_bind.* src=[[:digit:]]*' /var/log/audit/audit.log | wc -l
1

Comment 3 Matthias Runge 2014-03-25 10:32:47 UTC
Any progress in this bug here? Peter? Thanks to John, we do have a fix for this issue.

Comment 4 Matthias Runge 2014-03-25 10:34:48 UTC
f20 version is affected as well.

Comment 5 Hugh Brock 2014-03-31 15:47:07 UTC
Is this thing on? We've had a patch since January, can we get it applied?

Comment 6 Richard W.M. Jones 2014-03-31 16:01:05 UTC
I've just applied this to Rawhide.  Once I get it to build
I'll see if the SELinux problems are solved or not.

If that goes well, we'll see about F20.

Comment 7 Richard W.M. Jones 2014-03-31 16:01:58 UTC
Also, I'm not clear what should be the upstream status of this
patch.  It's a very minor patch, but I suspect one which is not
going to be friendly for upstream (doubt they want long-standing
ports to be changed just to make SELinux happy, even if they are
wrong).

Comment 8 Richard W.M. Jones 2014-03-31 16:33:34 UTC
Works for me in Rawhide.  I intend to backport this
to Fedora 20 (because of comment 4).  The original BZ
is against Fedora 19, but I don't know if we should
update such an old version at this time.

Comment 9 Fedora Update System 2014-03-31 16:58:37 UTC
rabbitmq-server-3.1.5-4.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/rabbitmq-server-3.1.5-4.fc20

Comment 10 lnie 2014-04-01 08:03:55 UTC
unable to install rabbitmq-server-3.1.5-4.fc20,
with the following output:
Transaction check error:
  file /usr/share/man/man1/vim.1.gz from install of vim-common-2:7.4.179-1.fc20.x86_64 conflicts with file from package vim-minimal-2:7.4.027-2.fc20.x86_64

Comment 11 Richard W.M. Jones 2014-04-01 08:07:31 UTC
(In reply to lnie from comment #10)
> unable to install rabbitmq-server-3.1.5-4.fc20,
> with the following output:
> Transaction check error:
>   file /usr/share/man/man1/vim.1.gz from install of
> vim-common-2:7.4.179-1.fc20.x86_64 conflicts with file from package
> vim-minimal-2:7.4.027-2.fc20.x86_64

That seems to have nothing to do with rabbitmq.  Can you
remove one of those packages, and/or open a new bug against vim.

Comment 12 Richard W.M. Jones 2014-04-01 08:10:15 UTC
In fact the vim bug is this one:
https://bugzilla.redhat.com/show_bug.cgi?id=1066983
It's a packaging bug in vim.

Comment 13 lnie 2014-04-01 08:53:38 UTC
(In reply to Richard W.M. Jones from comment #12)
> In fact the vim bug is this one:
> https://bugzilla.redhat.com/show_bug.cgi?id=1066983
> It's a packaging bug in vim.

yeah,it's a vim bug. The rabbitmq-server is installed successfully,and works well,after I have that bug gone on my test machine.

Comment 14 Fedora Update System 2014-04-02 09:20:53 UTC
Package rabbitmq-server-3.1.5-4.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing rabbitmq-server-3.1.5-4.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-4663/rabbitmq-server-3.1.5-4.fc20
then log in and leave karma (feedback).

Comment 15 Fedora Update System 2014-04-14 22:38:12 UTC
rabbitmq-server-3.1.5-4.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 16 John Eckersberg 2014-11-05 19:10:09 UTC
*** Bug 1036280 has been marked as a duplicate of this bug. ***