Bug 597858

Are you using any plugins that could be causing this avc?

I also just got hit with this problem.  Have nspluginwrapper installed, and tried setsebool -P allow_unconfined_nsplugin_transition=0, without success.

The rest of my original comment was cut off, I will try to identify which plugin is the cause.  I just noticed this today after installing selinux-policy 3.8.1-4, but since I switched my default browser to chrome, it may have going on since 3.8.1-3.

setsebool -P allow_execmem 0

Will fix this for now.  I am not sure if there is a great way to fix this other then turning this boolean on.

One other option would be to set the chromium browser context to execmem_exec_t.

I am now up to selinux-policy* 3.8.1-5.  Executing setsebool -P allow_execmem 0 does not solve the problem, The error still comes up with Firefox:


Summary:

SELinux is preventing firefox from making its memory writable and executable.

Detailed Description:

The firefox application attempted to change the access protection of memory
(e.g., allocated using malloc). This is a potential security problem. Firefox is
probably not the problem here ,but one of its plugins. You could remove the
plugin and the app would no longer require the access. If you figure out which
plugin is causing the access request, please open a bug report on the plugin.

Allowing Access:

There are two ways to fix this problem, you can install the nsspluginwrapper
package, which will cause firefox to run its plugins under a separate process.
This process will allow the execmem access. This is the safest choice. You could
also turn off the allow_unconfined_nsplugin_transition boolean.
setsebool -P allow_unconfined_nsplugin_transition=0

Fix Command:

yum install nspluginwrapper

Additional Information:

Source Context                unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1
                              023
Target Context                unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1
                              023
Target Objects                None [ process ]
Source                        firefox
Source Path                   /usr/lib/firefox-3.6/firefox
Port                          <Unknown>
Host                          Fedora14dw32
Source RPM Packages           firefox-3.6.3-4.fc14
Target RPM Packages           
Policy RPM                    selinux-policy-3.8.1-5.fc14
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Plugin Name                   firefox
Host Name                     Fedora14dw32
Platform                      Linux Fedora14dw32 2.6.34-20.fc14.i686.PAE #1 SMP
                              Wed Jun 2 12:53:34 UTC 2010 i686 i686
Alert Count                   6
First Seen                    Wed 02 Jun 2010 04:46:38 PM EDT
Last Seen                     Thu 03 Jun 2010 10:47:08 PM EDT
Local ID                      4461206b-ecb7-4c88-b752-27d9785f08a4
Line Numbers                  

Raw Audit Messages            

node=Fedora14dw32 type=AVC msg=audit(1275619628.527:25197): avc:  denied  { execmem } for  pid=2361 comm="firefox" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process

node=Fedora14dw32 type=SYSCALL msg=audit(1275619628.527:25197): arch=40000003 syscall=192 success=no exit=-13 a0=0 a1=10000 a2=7 a3=22 items=0 ppid=2344 pid=2361 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="firefox" exe="/usr/lib/firefox-3.6/firefox" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)

I wasn't clear on Comment #3, I did switch my default browser to chrome, but, I am not getting errors with chrome, just Firefox.  I still haven't narrowed down which addon is causing the problem.

Additional /var/log/messages: Before and after setsebool -P allow_execmem 0

Jun  3 22:45:40 localhost kernel: Process 2263(firefox) has RLIMIT_CORE set to 0
Jun  3 22:45:40 localhost kernel: Aborting core
Jun  3 22:45:42 localhost setroubleshoot: SELinux is preventing firefox from making its memory writable and executable. For complete SELinux messages. run sealert -l 4461206b-ecb7-4c88-b752-27d9785f08a4
Jun  3 22:46:56 localhost dbus: avc:  received policyload notice (seqno=2)
Jun  3 22:46:56 localhost dbus: avc:  received policyload notice (seqno=2)
Jun  3 22:46:56 localhost dbus: [system] Reloaded configuration
Jun  3 22:46:56 localhost setsebool: The allow_execmem policy boolean was changed to 0 by root
Jun  3 22:47:08 localhost kernel: Process 2361(firefox) has RLIMIT_CORE set to 0
Jun  3 22:47:08 localhost kernel: Aborting core
Jun  3 22:47:10 localhost setroubleshoot: SELinux is preventing firefox from making its memory writable and executable. For complete SELinux messages. run sealert -l 4461206b-ecb7-4c88-b752-27d9785f08a4
Jun  3 22:56:07 localhost kernel: show_signal_msg: 24 callbacks suppressed
Jun  3 22:56:07 localhost kernel: gedit[2223]: segfault at 0 ip 06bd8b7b sp bfd42a10 error 4 in libgconf-2.so.4.1.5[6bbd000+37000]
Jun  3 22:56:07 localhost kernel: Process 2223(gedit) has RLIMIT_CORE set to 0
Jun  3 22:56:07 localhost kernel: Aborting core

This is happening to me with firefox-3.6.4-2.fc14.i686 and nspluginwrapper-1.3.0-14.fc14.i686 with all plugins disabled; any attempt to fire up the browser triggers the selinux detection, and if I have enforcing instead of permissive, I cannot use firefox.

Same versions as https://bugzilla.redhat.com/show_bug.cgi?id=597858#c7

I have the following addons:
googlesharing
adblock plus

Just a note, I have experimented removing all the add-ons and still have the AVC denial.  I have spoke to others that have the same results removing all add-ons.  I think that at this point the focus should be shifted to another source of the problem.
Luckily, Chrome doesn't have these problems.

I can reproduce after removing nspluginwrapper.

(Forgive me for translating the summary from Polish to English - sorry but I would almost consider it a setroubleshoot bug.)

setroubleshoot is being rewritten now to fix this problem.  The translation and substitutions are happening at the time of the AVC and being written to the database.  Therefore we can not untranslate it.  The rewrite will do the translations and substitutions in the client, which will allow us to fix that problem.

firefox-3.6.4-2.fc14.x86_64 does not show this behavior.

Still exists in firefox 32bit.

If /usr/bin/firefox --safe-mode used
even if nothing checked, it starts without fault.
if --safe-mode removed the abrt\sealert are there.

*** Bug 603182 has been marked as a duplicate of this bug. ***

Some other reports:

https://bugzilla.redhat.com/buglist.cgi?short_desc=[abrt]%20firefox-3.6.4-2.fc14:%20Process%20was%20killed%20by%20signal%2011%20(SIGSEGV)&bug_status=__open__&short_desc_type=allwordssubstr

Adding to F14Alpha blocker list:

https://fedoraproject.org/wiki/Fedora_14_Alpha_Release_Criteria

Alpha Release Requirements:
13. It must be possible to run the default web browser and a terminal application from the default desktop environment.

Discussed at the 2010/07/23 blocker bug review meeting, we accept this as a blocker.

This seems to be a merry-go-round that's been going since F12: we try to apply a tighter SELinux policy, Firefox fails it, we loosen it up for release since Firefox won't get fixed.

It seems like a patch is done on the upstream bug - https://bugzilla.mozilla.org/show_bug.cgi?id=506693 - but upstream is dragging their feet accepting it, and of course, Firefox being Firefox, we can't apply it downstream. The critical thread of conversation I see is:

Comment #99 from Mozilla side: "Before we take this patch, I want us to be clear on the security benefits we're going to get. Please, no sermonizing on "privileges" and "rights".

What attacks does this patch prevent, and which ones does it leave open? Let's make the trade-offs extremely clear, so we have a record of our decision, if nothing else."

Comment #109 from our side: is an explanation of a potential attack scenario.

Then #111 and #112 note that we're still waiting for some kind of upstream decision, the source of which remains unclear.

Is there something we can do to escalate this with the Mozilla folks to at least make them give a definite decision to accept or reject the patch in a reasonable timeframe? Do we have any additional 'firepower' we can bring to bear on this upstream?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

(In reply to comment #17)
> It seems like a patch is done on the upstream bug -
> https://bugzilla.mozilla.org/show_bug.cgi?id=506693 - but upstream is dragging
> their feet accepting it, and of course, Firefox being Firefox, we can't apply
> it downstream.

> Do we have any additional 'firepower' we can bring to bear on this upstream?

This reminds me of the flap about bug 579023 a few months ago, which was traced to a failure to escalate the bug to the Fedora package maintainers:

https://lists.fedoraproject.org/pipermail/devel/2010-April/135239.html

But this case might be different.  Fedora can't coerce Mozilla, but it can act in its own best interests as determined by FESCo.  Is this patch important enough to merit dropping the trademarks in the event that upstream does not act?  If so, Fedora should state that intent without further delay.

The Fedora firefox developers are clearly aware of this bug, as they've been responding to it both here and upstream all this time. :) At least, Jens is.

"Is this patch important enough to merit dropping the trademarks in the event that upstream does not act?"

Historically we haven't done that, instead we've just kept relaxing SELinux's restriction so Firefox will keep working. But it doesn't seem sane to keep doing that forever, this has to be addressed in a less workaround-y fashion *some* time.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

I know we can't coerce Mozilla, of course, but there are certainly people at RH and Mozilla who have existing relationships, which may help grease the wheels if we get them involved.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Well, I would appreciate a comment from one of the Fedora firefox maintainers at least.  Or do we just move this to selinux policy again?

(In reply to comment #21)
> Well, I would appreciate a comment from one of the Fedora firefox maintainers
> at least.  Or do we just move this to selinux policy again?    

It's not clear to me what they could do.  You can see the current situation for yourself here:

https://bugzilla.mozilla.org/show_bug.cgi?id=506693#c112

I filed https://fedorahosted.org/fesco/ticket/442 .

This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Discussed at today's blocker review meeting. This is still a blocker, and we need a decision made by Tuesday in order to be able to start spinning Alpha RCs. Thanks!



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

This bug is in NEEDINFO for a mail alias.  Is there anyone who can provide status on this F14Alpha blocker issue?  Adding caillon and mstransky for ideas.

*** Bug 608428 has been marked as a duplicate of this bug. ***

This is probably a dupe of https://bugzilla.redhat.com/show_bug.cgi?id=gecko-execmem which has been known for a while and is being worked on with upstream.  This isn't really new behavior or anything, so not sure why this is suddenly a blocker.

(In reply to comment #28)
> This isn't really new
> behavior or anything, so not sure why this is suddenly a blocker.    

It is a blocker now that the SELinux policy has been tightened again for F14.

setroubleshoot is launching

/usr/bin/xdg-open

Which should launch the default browser.

Daniel, I see the avc coming from firefox though.
Is xdg-open another issue?

This happens in x86_64 for me F14\F15, just notices -all +i686

An updated selinux-policy is available in F14 that re-enable allow_execmem and allow_execmod booleans.  A bodhi update and positive karma will be needed to get this into F14-Alpha

http://koji.fedoraproject.org/koji/buildinfo?buildID=188080

* Tue Aug 03 2010 Dan Walsh <dwalsh> 3.8.8-9
 - Apply Miroslav munin patch - Turn back on allow_execmem and allow_execmod booleans

I'm going to remove F14Alpha once we've confirmed that the updated selinux-policy is available and works around this problem.

Fixed in selinux-policy-3.8.8-10.fc14.noarch

selinux-policy-3.8.8-10.fc14 has been submitted as an update for Fedora 14.
http://admin.fedoraproject.org/updates/selinux-policy-3.8.8-10.fc14

Dan, please don't close the bug until the update goes through. We can't consider it closed until the package is actually in F14 composes, and that doesn't happen till the update is pushed.

Thanks!  Confirmed, fixed in selinux-policy-3.8.8-10.fc14 on
install of F14 i686 nightly Live.

selinux-policy-3.8.8-10 is included in F-14-Alpha-RC1, and the fix is confirmed based on comment#38.  Moving to VERIFIED.

How long before this also makes it into rawhide?  Right now, rawhide is stuck at selinux-policy-3.8.8-8.fc14.noarch, and still fails.

(In reply to comment #40)
> How long before this also makes it into rawhide?  Right now, rawhide is stuck
> at selinux-policy-3.8.8-8.fc14.noarch, and still fails.    
 
This works in Rawhide: Check my comment.
http://admin.fedoraproject.org/updates/selinux-policy-3.8.8-10.fc14

I still see this problem with the Fedora 14 Alpha RC2.

Steps to reproduce:

1) Install i386 DVD ISO to a KVM guest
2) answer firstboot questions and create a non-priv user
3) log in as non-priv user
4) run firefox from gnome pannel
5) kaboom!

(In reply to comment #42)
> I still see this problem with the Fedora 14 Alpha RC2.

Can you restest with https://admin.fedoraproject.org/updates/selinux-policy-3.8.8-10.fc14 ?

Moving back to VERIFIED. I believe this issue has been worked around with the updated selinux-policy based on other test feedback.  We're looking into updating the mirrors to have this package.

selinux-policy-3.8.8-10.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

This will not fix the problem on an update, only on a fresh install.



You can fix it on an existing machine by executing

# setsebool -P allow_execmem 1