Bug 375041 - SELinux is preventing ld-linux.so.2 from changing the access protection of memory on the heap.
Summary: SELinux is preventing ld-linux.so.2 from changing the access protection of me...
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: setroubleshoot
Version: 8
Hardware: i686
OS: Linux
low
high
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-11-10 21:22 UTC by Konstantin Svist
Modified: 2008-09-10 20:16 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-09-10 20:16:46 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Konstantin Svist 2007-11-10 21:22:19 UTC
Description of problem:

setroubleshoot kept reporting this problem every few seconds, until I closed
some webpages in Firefox. I'm not 100% sure if this bug should be filed against
Firefox because setroubleshoot doesn't mention the package...

Full setroubleshoot message:

"""
Summary
    SELinux is preventing ld-linux.so.2 from changing the access protection of
    memory on the heap.

Detailed Description
    The ld-linux.so.2 application attempted to change the access protection of
    memory on the heap (e.g., allocated using malloc).  This is a potential
    security problem.  Applications should not be doing this. Applications are
    sometimes coded incorrectly and request this permission.  The
    http://people.redhat.com/drepper/selinux-mem.html web page explains how to
    remove this requirement.  If ld-linux.so.2 does not work and you need it to
    work, you can configure SELinux temporarily to allow this access until the
    application is fixed. Please file a
    http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package.

Allowing Access
    If you want ld-linux.so.2 to continue, you must turn on the allow_execheap
    boolean.  Note: This boolean will affect all applications on the system.

    The following command will allow this access:
    setsebool -P allow_execheap=1

Additional Information        

Source Context                unconfined_u:unconfined_r:unconfined_crond_t:s0
Target Context                unconfined_u:unconfined_r:unconfined_crond_t:s0
Target Objects                None [ process ]
Affected RPM Packages         
Policy RPM                    selinux-policy-3.0.8-44.fc8
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   plugins.allow_execheap
Host Name                     mireille
Platform                      Linux mireille 2.6.23.1-42.fc8 #1 SMP Tue Oct 30
                              13:55:12 EDT 2007 i686 i686
Alert Count                   93
First Seen                    Sat 10 Nov 2007 04:25:48 AM PST
Last Seen                     Sat 10 Nov 2007 04:28:53 AM PST
Local ID                      97b65209-50d4-4192-87ec-8f71c15b177a
Line Numbers                  

Raw Audit Messages            

avc: denied { execheap } for comm=ld-linux.so.2 pid=16624
scontext=unconfined_u:unconfined_r:unconfined_crond_t:s0 tclass=process
tcontext=unconfined_u:unconfined_r:unconfined_crond_t:s0
"""


Version-Release number of selected component (if applicable):
Firefox version is 2.0.0.8


Steps to Reproduce:
1. Unknown

Comment 1 Daniel Walsh 2007-11-12 20:53:47 UTC
That is strange, since this is reporting crond trying to do some weird stuff.

This is reporting some crond is running an application in cron that requires
execheap?  

Can you tell me what web pages triggered this?  And are you sure firefox was the
triffer?  This is very strange.

Comment 2 Daniel Walsh 2007-11-12 20:56:25 UTC
How is your mono executable labeled?

ls -lZ /usr/bin/mono

Also when you are logged in, what is your context 

id -Z

Comment 3 Konstantin Svist 2007-11-12 21:14:13 UTC
# ls -lZ /usr/bin/mono
-rwxr-xr-x  root root system_u:object_r:mono_exec_t:s0 /usr/bin/mono

# id -Z
system_u:system_r:unconfined_t:s0

$ id -Z
system_u:system_r:unconfined_t:s0

I'm NOT sure if it was firefox.. nor am I sure which page(s) triggered this.


Comment 4 Daniel Walsh 2007-11-12 21:40:50 UTC
Ok, probably not,  If it happens again, try to see what processes cron is
running that is causing the problem.  You can execute the setsebool
allow_execheap if you just want it to run, but it would be nice if we could
figure out which application is causing this.

Comment 5 Glen Shipley 2007-12-17 16:23:29 UTC
I believe I received this error when firefox was trying to download/install the
adobe flash player plugin. 

On a new installation I went to the www.verizon.net webpage. I clicked to
install the plugin. The adobe plugin failed to install. I saw this selinux
setroubleshoot entry. After finding this bugzilla bug thread online I deleted
the setroubleshoot entry. I'm not sure if that was what I was supposed to do to
try to recreate the condition. I went back to www.verizon.net and tried again to
install the plugin. This time it worked.

Anyway here is the additional info from my setroubleshoot entry:
Additional InformationSource
Context:  unconfined_u:unconfined_r:unconfined_crond_t:s0Target
Context:  unconfined_u:unconfined_r:unconfined_crond_t:s0Target Objects:  None [
process ]Affected RPM Packages:  Policy RPM:  selinux-policy-3.0.8-44.fc8Selinux
Enabled:  TruePolicy Type:  targetedMLS Enabled:  TrueEnforcing
Mode:  EnforcingPlugin Name:  plugins.allow_execheapHost
Name:  localhost.localdomainPlatform:  Linux localhost.localdomain
2.6.23.1-42.fc8 #1 SMP Tue Oct 30 13:55:12 EDT 2007 i686 i686Alert
Count:  5First Seen:  Mon 17 Dec 2007 04:11:40 AM ESTLast Seen:  Mon 17 Dec 2007
04:12:43 AM ESTLocal ID:  65a4825a-4949-4299-8b8f-1bace79384a8Line Numbers:  Raw
Audit Messages :avc: denied { execheap } for comm=ld-linux.so.2 pid=6008
scontext=unconfined_u:unconfined_r:unconfined_crond_t:s0 tclass=process
tcontext=unconfined_u:unconfined_r:unconfined_crond_t:s0 

Comment 6 Daniel Walsh 2007-12-17 20:49:13 UTC
If you execute crontab -e  Does it show anything?

Comment 7 Ian Hutchinson 2008-03-07 16:02:03 UTC
This problem has occurred for me on several occasions. One was when loading
the Adobe Reader (plugin) into Konqueror.

Raw Audit Messages :host=localhost type=AVC
msg=audit(1204904759.611:67): avc: denied { execheap } for pid=12033
comm="ld-linux.so.2"
scontext=unconfined_u:system_r:unconfined_t:s0-s0:c0.c1023
tcontext=unconfined_u:system_r:unconfined_t:s0-s0:c0.c1023
tclass=process

12019 ?        S      0:00 kio_http [kdeinit] 
http /tmp/ksocket-hutch/klauncherpdmKOb  
12024 ?        S      0:15 /usr/bin/nspluginviewer -dcopid nspluginviewer-6676
12033 ?        S      
0:02 /lib/ld-linux.so.2 /opt/Adobe/Reader8/Reader/intellinux/bin/acroread --display :0.0 -progressPipe 
3 -exit
12083 ?        S      0:00 kio_http [kdeinit] 
http /tmp/ksocket-hutch/klauncherpdmKOb  


There may have been others. I have evidence to suggest that this bug is the
cause of a major melt-down of my system on two prior occasions. Therefore it
is potentially serious.


Comment 8 Daniel Walsh 2008-03-10 13:52:58 UTC
Well your problem is different.  Your problem shows that nsplugin/acroread is
asking for execheap, which can be considered a security hazard.  It might just
be bad coding on Adobe's part, or I guess they could really require it.  This
link describes the problem.

http://people.redhat.com/~drepper/selinux-mem.html

So in your case you can turn on the allow_execheap boolean if you want and
complain to Adobe, or just use evince.

The previous AVC's in the bugzilla show a cron job running on behalf of the user
requiring execheap.  This seems like it could be a security hazard.  Something
on these pages is kicking off a cron job.

Comment 9 Daniel Walsh 2008-09-10 20:16:46 UTC
Has this problem gone away.  I am cleaning up old Messages and saw this.  Will close as WORKSFORME,  Repoen if it is still a problem.


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