Bug 197626 - pthread_create fails when called from application with an executable stack (selinux)
pthread_create fails when called from application with an executable stack (s...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Eric Paris
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-07-04 19:00 EDT by Hans de Goede
Modified: 2007-11-30 17:11 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-04 12:27:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Hans de Goede 2006-07-04 19:00:52 EDT
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.
Comment 1 Jakub Jelinek 2006-07-05 09:08:06 EDT
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
the memory.
Comment 2 Hans de Goede 2006-07-05 09:12:33 EDT
(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.

Comment 3 Daniel Walsh 2006-07-10 10:27:34 EDT
I don't see why this is assigned to the  selinux-policy package.  Which package
should this be applied to?  Kernel?  Glibc?
Comment 4 Stephen Smalley 2006-07-11 10:29:06 EDT
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
allow both.

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: 
denied" messages.
Comment 5 Hans de Goede 2006-07-14 10:39:13 EDT
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
will work).
Comment 6 Eric Paris 2006-07-19 14:18:15 EDT
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?
Comment 8 Eric Paris 2006-07-20 13:37:51 EDT
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
concerns raised.
Comment 9 Hans de Goede 2006-07-20 17:01:17 EDT
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.

Comment 10 Eric Paris 2006-07-21 12:04:48 EDT
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.
Comment 11 Eric Paris 2006-08-04 12:27:21 EDT
Closing bug.  Hopefully setroubleshoot will continue to evolve rapidly and will
help to inform users of SELinux denials in a timely manor.

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