Bug 188006 - curl generates execmem and execstack avc granted log messages
Summary: curl generates execmem and execstack avc granted log messages
Alias: None
Product: Fedora
Classification: Fedora
Component: curl
Version: 5
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Ivana Varekova
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2006-04-05 11:21 UTC by Paul Howarth
Modified: 2007-11-30 22:11 UTC (History)
3 users (show)

Clone Of:
Last Closed: 2006-04-05 17:20:59 UTC

Attachments (Terms of Use)

Description Paul Howarth 2006-04-05 11:21:00 UTC
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"
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"
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

  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

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

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.

Comment 1 Daniel Stenberg 2006-04-05 11:40:55 UTC
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!

Comment 2 Paul Howarth 2006-04-05 11:44:31 UTC
Some information on what's being checked and possible workarounds can be found at:


Unfortunately I don't know anything about curl's internals myself so I can't
help with a patch.

Comment 3 Daniel Stenberg 2006-04-05 12:08:36 UTC
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?

Comment 4 Ulrich Drepper 2006-04-05 16:32:10 UTC
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.

Comment 5 Paul Howarth 2006-04-05 17:20:59 UTC
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

Thanks for the clue.

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