Bug 1901466 - ejabberd won't start - SELinux denials
Summary: ejabberd won't start - SELinux denials
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: ejabberd
Version: 33
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Peter Lemenkov
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-11-25 10:53 UTC by Russell Odom
Modified: 2021-08-25 20:04 UTC (History)
6 users (show)

Fixed In Version: ejabberd-20.07-5.fc36, ejabberd-20.07-5.fc35 ejabberd-20.07-3.fc34 ejabberd-20.07-2.fc33
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-08-25 19:54:23 UTC
Type: Bug


Attachments (Terms of Use)

Description Russell Odom 2020-11-25 10:53:29 UTC
Description of problem:
ejabberd won't start, due to SELinux denials, after upgrade from F31 to F33.

Version-Release number of selected component (if applicable):
ejabberd-20.07-1.fc33.noarch

How reproducible:
Every time

Steps to Reproduce:
1. Upgrade system with ejabberd from F31 to F33 (I don't know if this is a required step)
2. Attempt to start ejabberd

Actual results:
`journalctl -u ejabberd`:
Nov 24 14:58:57 host.example.com systemd[1]: Starting A distributed, fault-tolerant Jabber/XMPP server...
Nov 24 15:00:27 host.example.com systemd[1]: ejabberd.service: start operation timed out. Terminating.
Nov 24 15:00:29 host.example.com systemd[1]: ejabberd.service: Failed with result 'timeout'.
Nov 24 15:00:29 host.example.com systemd[1]: Failed to start A distributed, fault-tolerant Jabber/XMPP server.


SELinux denials (in permissive mode):
Nov 23 16:34:19 host.example.com audit[139545]: AVC avc:  denied  { search } for  pid=139545 comm="beam.smp" name="/" dev="cgroup2" ino=1 scontext=system_u:system_r:ejabberd_t:s0 tcontext=system_u:object_r:cgroup_t:s0 tclass=dir permissive=1
Nov 23 16:34:19 host.example.com audit[139545]: AVC avc:  denied  { read } for  pid=139545 comm="beam.smp" name="cgroup.controllers" dev="cgroup2" ino=4 scontext=system_u:system_r:ejabberd_t:s0 tcontext=system_u:object_r:cgroup_t:s0 tclass=file permissive=1
Nov 23 16:34:19 host.example.com audit[139545]: AVC avc:  denied  { open } for  pid=139545 comm="beam.smp" path="/sys/fs/cgroup/cgroup.controllers" dev="cgroup2" ino=4 scontext=system_u:system_r:ejabberd_t:s0 tcontext=system_u:object_r:cgroup_t:s0 tclass=file permissive=1
Nov 23 16:34:20 host.example.com audit[139545]: AVC avc:  denied  { name_bind } for  pid=139545 comm="2_scheduler" src=3478 scontext=system_u:system_r:ejabberd_t:s0 tcontext=system_u:object_r:unreserved_port_t:s0 tclass=udp_socket permissive=1


Expected results:
ejabberd starts

Additional info:
See also bug 1577363 and bug 1809085.

Comment 1 Michael Kuhn 2020-11-29 11:14:14 UTC
I can confirm this. After upgrading my server from Fedora 32 to Fedora 33 and updating the configuration, ejabberd didn't start anymore. This seems to be due to the new STUN service that's present in the default configuration:

>  -
>    port: 3478
>    ip: "::"
>    transport: udp
>    module: ejabberd_stun
>    use_turn: true
>    ## The server's public IPv4 address:
>    # turn_ipv4_address: "203.0.113.3"
>    ## The server's public IPv6 address:
>    # turn_ipv6_address: "2001:db8::3"

If I comment this out, ejabberd starts again. The name_bind denial seems to be the only one preventing ejabberd from starting.

Comment 2 Randy Barlow 2021-08-08 04:31:14 UTC
I think you can turn a boolean on to allow ejabberd to do that name bind, like this:

$ sudo semanage boolean --on nis_enabled

Comment 3 Fedora Update System 2021-08-17 04:48:35 UTC
FEDORA-2021-f8d7785a5d has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-f8d7785a5d

Comment 4 Randy Barlow 2021-08-17 05:08:38 UTC
I believe I have a fix for the SELinux policy in the builds associated with this ticket (should be fixed in F33-F36), and with the fixed build you should not need to enable the nis_enabled bool that I mentioned in Comment 2.

Comment 5 Randy Barlow 2021-08-17 05:09:03 UTC
F33 update: https://bodhi.fedoraproject.org/updates/FEDORA-2021-fd910a2e59

Comment 6 Fedora Update System 2021-08-18 01:21:42 UTC
FEDORA-2021-fd910a2e59 has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-fd910a2e59`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-fd910a2e59

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 7 Fedora Update System 2021-08-18 01:54:22 UTC
FEDORA-2021-f8d7785a5d has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-f8d7785a5d`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-f8d7785a5d

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 8 Fedora Update System 2021-08-25 19:54:23 UTC
FEDORA-2021-f8d7785a5d has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 9 Fedora Update System 2021-08-25 20:04:10 UTC
FEDORA-2021-fd910a2e59 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.


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