Bug 418131 - Ejabberd cannot work over secure connection
Ejabberd cannot work over secure connection
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: ejabberd (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Peter Lemenkov
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-10 09:39 EST by Matěj Cepl
Modified: 2008-02-07 16:00 EST (History)
0 users

See Also:
Fixed In Version: 2.0.0-0.3.rc1.fc7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-07 15:58:05 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
erl_crash.dump (220 bytes, text/plain)
2007-12-14 18:08 EST, Matěj Cepl
no flags Details
sasl.log (12.58 KB, text/plain)
2007-12-14 18:08 EST, Matěj Cepl
no flags Details
correct version of erl_crash.dump (243.52 KB, text/plain)
2007-12-15 12:32 EST, Matěj Cepl
no flags Details

  None (edit)
Description Matěj Cepl 2007-12-10 09:39:30 EST
Description of problem:
yum upgrade breaks on having incorrect version of libsecure and libssl.

Version-Release number of selected component (if applicable):
ejabberd.i386-1.1.4-1.fc8

How reproducible:
100%

Steps to Reproduce:
1. yum upgrade
2.
3.
  
Actual results:
breaks on couple of packages being broken -- ejabberd is one of them.

Expected results:
it should just work

Additional info:
Comment 2 Matěj Cepl 2007-12-14 18:05:15 EST
Actually, although the recompile works well (with patch I'got from the upstream
bug tracking database, because otherwise ejabberd doesn't compile with the
newest erlang we have in Rawhide; apparently, according to folks on
ejabberd@conference.jabber.ru we are pretty wild using pretty unstable Erlang; I
have to explain them that in Rawhide it is expected to have everything broken ;-))

However, when restarting compiled program ejabberd crashes:

[root@hubmaier ~]# service ejabberd stop
Shutting down ejabberd:                                    [  OK  ]
[root@hubmaier ~]# service ejabberd start
Spouštím ejabberd:                                         [  OK  ]
[root@hubmaier ~]# service ejabberd status
Node ejabberd@hubmaier is started. Status: started
ejabberd is not running
[root@hubmaier ~]# ejabberdctl ejabberd@localhost
RPC failed on the node ejabberd@localhost: nodedown

=ERROR REPORT==== 15-Dec-2007::00:01:29 ===
Error in process <0.33.0> on node 'ejabberdctl@hubmaier' with exit value:
{badarg,[{erlang,list_to_existing_atom,["ejabberd@hubmaier"]},{dist_util,recv_challenge,1},{dist_util,handshake_we_started,1}]}

[root@hubmaier ~]# 
Comment 3 Matěj Cepl 2007-12-14 18:08:17 EST
Created attachment 289611 [details]
erl_crash.dump
Comment 4 Matěj Cepl 2007-12-14 18:08:58 EST
Created attachment 289621 [details]
sasl.log
Comment 5 Matěj Cepl 2007-12-14 18:10:52 EST
/var/log/ejabberd/ejabberd.log is zero length
Comment 6 Matěj Cepl 2007-12-14 20:00:32 EST
Upsteram bug https://support.process-one.net/browse/EJAB-459
Comment 7 Matěj Cepl 2007-12-15 12:30:36 EST
from ejabberd@conference.jabber.ru:

[01:57:24] mcepl: https://support.process-one.net/browse/EJAB-459
[11:20:29] badlop: mcepl: in your logs:
    exception exit: {bad_return,{{ejabberd_app,start,[normal,[]]},
                                 {'EXIT',"permission denied"}}}
[11:20:39] badlop: did you investigate this?
[12:42:58] mcepl: badlop: well, the question is permission to what are denied?
[12:44:12] badlop: to strinpret.so or other .so files installed by ejabberd?
[12:44:58] mcepl: OK, I will investigate that.
[...]
[17:21:34] mcepl: badlop: ping (is it enough that all files in ejabberd package
are readable/executable by ejabberd user)?
[17:22:41] mcepl: what is bean.smp? I guess it was broken by selinux
[17:23:33] badlop: i think yes
[17:23:50] badlop: beam.smp might be a beam version with support for SMP
[17:24:25] badlop: beam: binary erlang architecture machine
[17:24:32] badlop: or something like that 
[17:26:10] badlop: A is for abstract
[17:26:12] mcepl: but I have permissive selinux so it shouldn't break anything
[17:26:21] mcepl: oh well -- selinux is weird these days in Rawhide
Comment 8 Matěj Cepl 2007-12-15 12:32:48 EST
Created attachment 289691 [details]
correct version of erl_crash.dump
Comment 9 Peter Lemenkov 2007-12-15 13:07:36 EST
(In reply to comment #2)
> Actually, although the recompile works well (with patch I'got from the upstream
> bug tracking database, because otherwise ejabberd doesn't compile with the
> newest erlang we have in Rawhide; apparently, according to folks on
> ejabberd@conference.jabber.ru we are pretty wild using pretty unstable Erlang; 

Erlang R12-0 has many advantages over last version so we'd better stay with
latest one :). BTW odbc may be hardly broken too (R12-0 has some differences in
odbc-realisation).

Returning to subj - the main problem is selinux-related, as I understand. 
Comment 10 Matěj Cepl 2007-12-15 15:34:26 EST
I am not sure about that -- I have Selinux in permissive mode, so it shouldn't
be a factor (although the current history of hal in Rawhide suggest otherwise).
Comment 11 Matěj Cepl 2007-12-16 17:19:37 EST
note to myself -- check permissions on /etc/ejabberd/*
Comment 12 Matěj Cepl 2007-12-16 18:14:45 EST
(In reply to comment #9)
> Returning to subj - the main problem is selinux-related, as I understand. 

my comment 10 shouldn't mean that there is no problem with SELinux (it may just
mercilessly covered by the permissive mode) and the reason why beam.smp is
denied execmem is interesting one.
Comment 13 Matěj Cepl 2007-12-17 17:44:26 EST
to comment 11:

yes, permissions in /etc/ejabberd/* were helpful -- when fixed ownership to
ejabberd:ejabberd to all files there and chmod to 640 the server runs and I can
connect to it.

to comment 9:

yes, it is SELinux -- when testing with binary install from ejabberd site,
everything works smoothly, but with Fedora packaged ejabberd I get:

type=AVC msg=audit(1197926176.301:431): avc:  denied  { execmem } for  pid=13101
 comm="beam.smp" scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:system
_r:initrc_t:s0 tclass=process
type=SYSCALL msg=audit(1197926176.301:431): arch=c000003e syscall=9 per=400000
success=yes exit=1073741824 a0=0 a1=a01000 a2=7 a3=62 items=0 ppid=13100
pid=13101 auid=500 uid=498 gid=497 euid=498 suid=498 fsuid=498 egid=497 sgid=497
fsgid=497 tty=(none) comm="beam.smp"
exe="/usr/lib64/erlang/erts-5.6/bin/beam.smp" subj=system_u:system_r:initrc_t:s0
key=(null)

(full /var/log/audit/audit.log is going to be attached for Dan's enjoyment)
Comment 15 Matěj Cepl 2007-12-17 17:53:03 EST
sorry, it's too late and I forgot the most important stuff -- the problems
presents itself as me being not able to send a message anywhere and not able to
connect to any MUC.
Comment 16 Daniel Walsh 2007-12-18 08:56:18 EST
Is ejabberd a java application?

Where is it installed?

If it is a java app can you set the context to java_exec_t and does the AVC go away.

chcon -t java_exec_t PATHTOAP
Comment 17 Peter Lemenkov 2007-12-18 09:03:32 EST
(In reply to comment #16)
> Is ejabberd a java application?

Ejabberd is in no way related to Java. It is a pure erlang-application. 
Comment 18 Daniel Walsh 2007-12-18 10:20:28 EST
Ok, I have no idea what erlang is,  But it is asking for execmem privledge which
is considered a potential security risk.

http://people.redhat.com/~drepper/selinux-mem.html

Certain languages require the ability to execute writeable memory java, mono. 
So we allow those apps to work, but a lot of time programs don't need it and are
poorly coded.  You can label the executable unconfined_execmem_exec_t and then
it should work in enforcing mode.

chcon -t unconfined_execmem_exec_t /usr/lib64/erlang/erts-5.6/bin/beam.smp

The best solution would be to write an SELinux policy for jabberd.
 
Comment 19 Matěj Cepl 2007-12-19 06:31:52 EST
(In reply to comment #16)
> Is ejabberd a java application?

http://en.wikipedia.org/wiki/Erlang_%28programming_language%29

[root@hubmaier ~]# rpm -qi erlang
Name        : erlang                       Relocations: (not relocatable)
Version     : R12B                              Vendor: Fedora Project
Release     : 0.1.fc9                       Build Date:
So 8. prosinec 2007, 13:05:27 CET
Install Date: Út 11. prosinec 2007, 01:20:02 CET      Build Host:
xenbuilder1.fedora.redhat.com
Group       : Development/Languages         Source RPM: erlang-R12B-0.1.fc9.src.rpm
Size        : 93239652                         License: Erlang Public License
Signature   : (none)
Packager    : Fedora Project
URL         : http://www.erlang.org
Summary     : General-purpose programming language and runtime environment
Description :
Erlang is a general-purpose programming language and runtime
environment. Erlang has built-in support for concurrency, distribution
and fault tolerance. Erlang is used in several large telecommunication
systems from Ericsson.
[root@hubmaier ~]# 
Comment 20 Matěj Cepl 2007-12-19 10:42:36 EST
The upstream bug is now https://support.process-one.net/browse/EJAB-431 (my bug
was duplicate of this one), and they blame some linking problems, which seems
irrelevant to our situation.

One more development -- when playing with the upstream binary installer, I
managed to get our packaged ejabberd to the same state as the upstream one. So I
can confirm the first half of my comment 13 -- fixing ownership of
/etc/ejabberd/* makes it working. Moreover, when I limit ejabberd to using
non-secure (i.e., no SSL, no TLS) connection to server, it works.

So, Dan, I think you are out of the loop on this bug, but we will probably
really need to work through some SELinux policy for Erlang -- if what makes
Java, Mono, et al. special for SELinux is that these are interpreted languages,
then Erlang is definitively in the same ballpark. Moreover, IIRC, it is language
which is specifically developed for writing huge server applications, so it
better be confined by SELinux.

And one last nitpicking note -- jabberd (C application) is not the same as
ejabberd (Erlang application), and they are not the same as jabberd2 (fork of
the jabberd C application).
Comment 21 Matěj Cepl 2007-12-26 18:16:48 EST
One more data point -- the problem goes away when 2.0.0-beta1 is used. Which
means  that I have two news for you -- one good and the other bad. The bad is
that I am not reproduce it anymore, so this should be closed as
INSUFFICIENT_DATA. The good news is that there is a package of ejabberd
2.0.0-beta1 build on Rawhide
http://koji.fedoraproject.org/koji/taskinfo?taskID=310599 and it seems to work
for me.

Of course, I don't know when the 2.0.0 will be actually released, so I don't
have any idea, whether we want to push beta version into Fedora.
Comment 22 Matěj Cepl 2007-12-29 16:46:55 EST
Dan, this is not good -- it's OK to remove you from the bug and remove SELinux
keyword if you don't want to be bothered by this (but, yes, I have still those
same AVC denials, but apparently ejabberd works happily with them in Permissive
mode), but I think ejabberd maintainers should decide whether to upgrade to
2.0.0 in Rawhide or not. I would love to see them to decide.

Reopening.
Comment 23 Matěj Cepl 2007-12-29 16:49:10 EST
And yes sorry my comment 21 was not clear enough about SELinux. The problem is
still there, it is the same execmem, I was just so happy that it works for me
that I forgot about SELinux issue (no, I am not crazy enough to run Rawhide with
Enforcing mode ;-)).
Comment 24 Fedora Update System 2008-01-27 02:14:48 EST
ejabberd-2.0.0-0.3.rc1.fc8 has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update ejabberd'.  You can provide feedback for this update here: http://admin.fedoraproject.org/F8/FEDORA-2008-1042
Comment 25 Fedora Update System 2008-02-07 15:57:56 EST
ejabberd-2.0.0-0.3.rc1.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 26 Fedora Update System 2008-02-07 16:00:31 EST
ejabberd-2.0.0-0.3.rc1.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, 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.