Red Hat Bugzilla – Bug 197626
pthread_create fails when called from application with an executable stack (selinux)
Last modified: 2007-11-30 17:11:36 EST
I've recently been having troubles with allegro apps hanging during
startup on my rawhide system.
This turns out to be selinux related, with selinux disabled they run fine.
The problem is that I have exec_stack allowed but not exec_mem, this
causes the apps to fail in a funny way. With execstack also disallowed
the error will be clear. What happens now is that when allegro creates a
thread pthread_create tries to create an anonymous rwx mem-mapping as
stack since the app has a exec stack, this anonymous rwx mem-mapping
creation is denied because its seen as exec_mem. This denying causes
allegro to hang forever in a futex_wait syscall.
The real problem here ofcourse is that app linked against allegro become
exec-stack. I'm working for a fix on this.
I however also believe that pthread_create should just work in the scenario
where we have an app which needs an executable stack calling pthread_create with
exec_stack allowed by selinux and exec_mem denied. Since it is trying to create
an executable stack and _that_ is allowed according to the policy settings.
Now I understand if fixing things to just work as expected is technically not
possible. In that case I would like to plea to add a message send to stderr to
pthread_create indicating that it failed because of this very special case, that
will help other people with similar problems fix it a lot faster then me. For
example realplayer suffers from the same problem.
1) pthread_create is not allowed to write anything to stderr
2) glibc has no way to detect the exact reason why the kernel chose not to mmap
(In reply to comment #1)
> 1) pthread_create is not allowed to write anything to stderr
Maybe use syslog then? Anything to make the cause more clear to the end user?
> 2) glibc has no way to detect the exact reason why the kernel chose not to mmap
> the memory.
In this case it sorta does as mmap returns permission denied, which afaik it
never does for an anonymous mmap without SELinux involved.
I don't see why this is assigned to the selinux-policy package. Which package
should this be applied to? Kernel? Glibc?
execmem is checked in a common code path for mmap and mprotect checking in the
case where an anonymous mapping is being made executable; it is always applied
to such mappings, regardless of any other check. execstack is only applied on
mprotect. The expectation is that you will always allow execmem if you need an
executable anon mapping for any purpose, and then you will further allow
execstack if you specifically need to make the stack executable. Ideally, you
disallow both. If the program needs to perform runtime code generation, you
allow execmem without execstack. If the program needs executable stack, you
SELinux denials should be audited, either to /var/log/messages if not running
auditd or to /var/log/audit/audit.log if running auditd. Look for "avc:
The denial is logged, that is not the problem, the problem is applications
failing (hanging) in weird ways with giving the end user a clue why. I'm a very
experienced C and kernel programmer and it took me about an hour to pinpoint
this! If we don't make the cause of this much clearer to the end user, all we
end up with is _everybody_ disabling selinux. Even I'm concidering disabling it
sometimes and I'm a security researcher as paid job!
Oh and I don't give a beep which component of Fedora / Linux is to blame, the
enduser should get somebetter error message then he currently does. This is just
like that other OS trying a dialog "an unknown error" has occured. Actually this
is worst since the application just stops responding completly! (only kill -9
Stephen would some sort of kernel exec_stack implies exec_mem be a good solution
to this situation? You indicate that if you want 1 you need the other... Turn
every check for exec_mem into exec_mem || exec_stack?
Did you have custom policy that you wrote for these applications? If so you
should fix the policy to allow both execmem and execstack. I checked all of
policy and actually the situation you describe doesn't seem to exist anywhere in
the policy we ship. I am going to submit a change to allow_execstack to try to
make sure we can never get into this situation when only using the policy we
ship. (I find it funny that ultimately our changes are going to be in the
package you opened the bug against)
With FC6 we should be shipping a new tool to better inform the user that selinux
denials have happened and to work with the user to get those fixed and working.
Hopefully by making sure this can't happen in our policy, and by providing
better notification to the user of potential problems we can fully address the
I don't completly understand what you mean with default policy. I've the default
policy except that a changed some sebools, does that count as a non default
policy? Ifso, then I do understand :)
I'm looking forward to the tools for better end user notification. Anything I
can test (I'm on rawhide)?
I think that if your satisfied that:
1) this won't happen with the default config
2) the end user will get better notification of selinux related problems
then this bug can be closed.
I believe the program is called 'setroubleshoot' and should be in rawhide. I
don't think it's been 'announced' yet and I know for a fact it's buggy and still
changing very rapidly but it should be moving in a good direction quickly.
Closing bug. Hopefully setroubleshoot will continue to evolve rapidly and will
help to inform users of SELinux denials in a timely manor.