Bug 197626

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.

(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
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.

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).

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
concerns raised.

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.