Bug 188006

Summary: curl generates execmem and execstack avc granted log messages
Product: [Fedora] Fedora Reporter: Paul Howarth <paul>
Component: curlAssignee: Ivana Varekova <varekova>
Status: CLOSED NOTABUG QA Contact:
Severity: low Docs Contact:
Priority: medium    
Version: 5CC: daniel, drepper, dwalsh
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-04-05 17:20:59 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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

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:

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.

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

Thanks for the clue.