Red Hat Bugzilla – Bug 188006
curl generates execmem and execstack avc granted log messages
Last modified: 2007-11-30 17:11:29 EST
Description of problem: Each invocation of curl generates a pair of SELinux avc log messages: Apr 5 12:18:29 goalkeeper kernel: audit(1144235909.820:2864): avc: granted { execstack } for pid=30725 comm="curl" scontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 tcontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 tclass=process Apr 5 12:18:29 goalkeeper kernel: audit(1144235909.820:2865): avc: granted { execmem } for pid=30725 comm="curl" scontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 tcontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 tclass=process Whilst these do not currently cause a problem as the corresponding booleans are enabled by default, they should probably be fixed upstream. The Fedora Wiki (http://fedoraproject.org/wiki/SELinux/FC5Features) says: We have started confining Userspace from these access checks, in Fedora Core 5. This is the beginning of allowing an administrator to confine userspace from malicious code. execmem and execstack by default are still allowed although you will see AVC granted messages in your log file. You can turn off these booleans and tighten your security by executing. setsebool -P allow_execmem=0 allow_execstack=0 We left these on, because of certain applications that were built incorrectly and need these privileges, especially the web browser plugins. We have worked hard to clean up all code shipped in Fedora to eliminate the need for these priviledges. If you see the granted message in your log files, you should open a bugzilla on those apps that require it, and copy me. :^) I have copied Daniel as requested. Version-Release number of selected component (if applicable): curl-7.15.1-1.2.1 How reproducible: Every time. Steps to Reproduce: 1. curl http://some.web.site/path/file.html Actual results: Log messages described above. Expected results: No such log entries. Additional info: Bug raised to track this issue. I'd think it would need fixing upstream rather than by patching in Fedora.
What exactly should we patch upstream? I don't have (access to) any box running FC5 nor any other SELinux so I would appreciate some further details, or preferably a suggested patch!
Some information on what's being checked and possible workarounds can be found at: http://people.redhat.com/drepper/selinux-mem.html Unfortunately I don't know anything about curl's internals myself so I can't help with a patch.
Sorry, but that page didn't make any bells ring... Is it perhaps possible to force a core dump for the possible violations so that a gdb backtrace would reveal where it occurs? Of course someone with this setup enabled could use gdb to step through the code to see when/why this alert happens. Or is there anything else I can do?
I don't see any such message when I use curl in a simple test. You'll have to provide a receipe to reproduce it. Also, adjust the hardware field of the bug to the one you see the bug on (unless you can really see the problem on more than one architecture). execstack errors are the easiest to track down. Just look at the DSOs which are loaded and look at their program header (eu-readelf -l /path/to/dso). There must be a GNU_STACK line. If this is missing or the permissions (second to last field) is RWX instead of RW you found the culprit.
Aha. Problem solved. I had a home-made libidn 0.6.3 package built on Red Hat 9 installed (with no GNU_STACK line). I built it on Red Hat 9 so it would install on later distro versions without dependency issues. Rebuilding on FC5 fixed the problem. Thanks for the clue.