Lordy, I've been having problems with this darn thing, so I hope someone can help me. :s
My troubles started when I downloaded the latest erlang and ejabberd packages. I crashed and burned very quickly, trying two or three different versions of erlang along with several of ejabberd 2.0.x.
Finally, after a week of pain, I admitted defeat, wiped the whole lot and installed the binary on the process-one website. Initially, the binary worked well, but mysteriously stopped working whenever I changed the config file and restarted the file.
Anyway, to cut a long story short, I have discovered that SELinux is preventing erlang from accessing its crypto libs. This message appears in the SELinux audit logs: type=AVC msg=audit(1223133076.770:102): avc: denied { execmod } for pid=3878 comm="beam.smp" path="/opt/ejabberd-2.0.2_2/lib/crypto-1.5.2/priv/linux-x86/lib/crypto_drv.so" dev=dm-0 ino=26738869 scontext=user_u:system_r:unconfined_t:s0 tcontext=user_u:object_r:usr_t:s0 tclass=file
What do I need to do, for selinux to allow this? (Or should I take this question to an SELinux list?)
FWIW, ejabberd seems to run fine while selinux is enabled. Its just when starting up, that it needs selinux to stay out of the way.
To answer my question, I have found the allow_execmem boolean, and set it.
So, should I file a bug with someone?
Also, I'm thinking I might run into more problems with SELinux silently interfering with ejabberd later on, so maybe I should disable SELinux and be done with it.
Does anyone here run ejabberd with SELinux enabled?
Damian S wrote:
To answer my question, I have found the allow_execmem boolean, and set it.
So, should I file a bug with someone?
Also, I'm thinking I might run into more problems with SELinux silently interfering with ejabberd later on, so maybe I should disable SELinux and be done with it.
That's what I'd suggest too. SELinux isn't even installed on any of the systems I manage(roughly 350). Not worth the trouble.
nate
On Sat, 2008-10-04 at 09:43 -0700, nate wrote:
Damian S wrote:
Also, I'm thinking I might run into more problems with SELinux silently interfering with ejabberd later on, so maybe I should disable SELinux and be done with it.
That's what I'd suggest too. SELinux isn't even installed on any of the systems I manage(roughly 350). Not worth the trouble.
Wow, 350 servers! :o
Although I run my dev machine in permissive mode because I need Zend Platform to provide remote PHP debugging, I'm desperately trying not to have to do the same to this and other servers. I'm not sufficiently good enough of an admin to not need help from selinux for a web-facing server.
Hi,
On Sat, Oct 4, 2008 at 12:43, nate centos@linuxpowered.net wrote:
so maybe I should disable SELinux and be done with it.
That's what I'd suggest too. SELinux isn't even installed on any of the systems I manage(roughly 350). Not worth the trouble.
That's a very bad advice.
SELinux is very useful as a security measure in Linux, and since RHEL5 (and CentOS 5) it has reached a good balance in terms of usability vs. security. I admit that making it work under the previous versions was very tricky, but with CentOS 5 it just works.
Of course you eventually have to tweak it to make it work for 3rd party programs (such as in the OP's case). In that case, this page may help you do it: http://wiki.centos.org/HowTos/SELinux
SELinux is certainly complex and there is a steep learning curve, but it's certainly worth learning how to use it and keeping it enabled.
Filipe
On Sat, Oct 4, 2008 at 10:25 AM, Damian S dsteward@internode.on.net wrote:
To answer my question, I have found the allow_execmem boolean, and set it.
So, should I file a bug with someone?
Also, I'm thinking I might run into more problems with SELinux silently interfering with ejabberd later on, so maybe I should disable SELinux and be done with it.
Well look at the problem.. your program is trying to execute code in the memory area of the stack versus the application. That is usually what exploit code does. So the first question I would ask is why is it acting like exploit code? Now certain languages do act like that because their concept of a stack is 'machine independant' (I think thats the correct term).. an example is Lisp which expects that you are running your code on a LISP machine which has a different memory manager than most modern day hardware. On the other hand, some uses a side effect to accomplish something because the programmer was being clever.. which usually bites someone later.
There are several paths you can go from here:
1) Run the system in passive mode. You won't be protected, but you can watch what might be causing issues later on. [Worst case, if you have an exploited machine and the logs aren't wiped.. you can figure out why... ] Anytime you have something doing crypto that way would have me wondering if some programmer was trying to be too clever.
2) Write a policy using audit2allow that would allow for ejabberd to execute on the stack but not other programs
3) Turn on the boolean which then allows any program to execute memory.
4) Turn off selinux.
Does anyone here run ejabberd with SELinux enabled?
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Sat, 2008-10-04 at 13:01 -0600, Stephen John Smoogen wrote:
On Sat, Oct 4, 2008 at 10:25 AM, Damian S dsteward@internode.on.net wrote:
Also, I'm thinking I might run into more problems with SELinux silently interfering with ejabberd later on, so maybe I should disable SELinux and be done with it.
Well look at the problem.. your program is trying to execute code in the memory area of the stack versus the application. That is usually what exploit code does. So the first question I would ask is why is it acting like exploit code? Now certain languages do act like that because their concept of a stack is 'machine independant' (I think thats the correct term).. an example is Lisp which expects that you are running your code on a LISP machine which has a different memory manager than most modern day hardware. On the other hand, some uses a side effect to accomplish something because the programmer was being clever.. which usually bites someone later.
Yes. This is erlang, so I've no doubt it does tricky things.
Ok so, I'll pester the process-one guys to either change this behaviour or write an selinux policy for ejabberd.
On Sun, 2008-10-05 at 03:02 +1100, Damian S wrote:
Anyway, to cut a long story short, I have discovered that SELinux is preventing erlang from accessing its crypto libs. This message appears in the SELinux audit logs: type=AVC msg=audit(1223133076.770:102): avc: denied { execmod } for pid=3878 comm="beam.smp" path="/opt/ejabberd-2.0.2_2/lib/crypto-1.5.2/priv/linux-x86/lib/crypto_drv.so" dev=dm-0 ino=26738869 scontext=user_u:system_r:unconfined_t:s0 tcontext=user_u:object_r:usr_t:s0 tclass=file
Just one final thing (hope it helps someone in future), according to Dan Walsh, much better (more fine-grained) than setting the allow_execmem boolean is to do this: chcon -t unconfined_execmem_exec_t /opt/ejabberd-2.0.2_2/bin/beam.smp
Damian S wrote:
Just one final thing (hope it helps someone in future), according to Dan Walsh, much better (more fine-grained) than setting the allow_execmem boolean is to do this: chcon -t unconfined_execmem_exec_t /opt/ejabberd-2.0.2_2/bin/beam.smp
And file this as something the rpm packager needs to look at for ejabberd, its not a bug in CentOS.
-
Damian S -
Filipe Brandenburger -
Karanbir Singh -
nate -
Stephen John Smoogen