Bug 998682 - SELinux denial when starting rabbitmq-server service
SELinux denial when starting rabbitmq-server service
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: rabbitmq-server (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Peter Lemenkov
Fedora Extras Quality Assurance
:
: 1036280 (view as bug list)
Depends On:
Blocks: 1032595
  Show dependency treegraph
 
Reported: 2013-08-19 14:51 EDT by James Slagle
Modified: 2014-11-05 14:10 EST (History)
11 users (show)

See Also:
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 18:38:12 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Use ephemeral port for probing (1.79 KB, patch)
2014-01-24 10:50 EST, John Eckersberg
no flags Details | Diff

  None (edit)
Description James Slagle 2013-08-19 14:51:50 EDT
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 10:50:22 EST
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 11:41:00 EDT
@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 06:32:47 EDT
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 06:34:48 EDT
f20 version is affected as well.
Comment 5 Hugh Brock 2014-03-31 11:47:07 EDT
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 12:01:05 EDT
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 12:01:58 EDT
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 12:33:34 EDT
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 12:58:37 EDT
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 04:03:55 EDT
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 04:07:31 EDT
(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 04:10:15 EDT
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 04:53:38 EDT
(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 05:20:53 EDT
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 18:38:12 EDT
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 14:10:09 EST
*** Bug 1036280 has been marked as a duplicate of this bug. ***

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