This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 597858 - "SELinux is preventing firefox from making its memory writable and executable." crashes rawhide firefox start
"SELinux is preventing firefox from making its memory writable and executable...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
14
i686 Linux
high Severity high
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
AcceptedBlocker setroubleshoot_trace_...
: Reopened
: 603182 608428 (view as bug list)
Depends On: gecko-execmem
Blocks: F14Blocker/F14FinalBlocker 609357 F14Alpha/F14AlphaBlocker
  Show dependency treegraph
 
Reported: 2010-05-30 15:14 EDT by Marek Paśnikowski
Modified: 2010-09-15 14:04 EDT (History)
24 users (show)

See Also:
Fixed In Version: selinux-policy-3.8.8-10.fc14
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-08-09 14:57:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Mozilla Foundation 506693 None None None Never

  None (edit)
Description Marek Paśnikowski 2010-05-30 15:14:40 EDT
Podsumowanie:

SELinux powstrzymuje Firefoksa przed ustawieniem swojej pamięci jako
zapisywalnej i wykonywalnej.

Szczegółowy opis:

[firefox posiada typ zezwalania (unconfined_t). Ten dostęp nie został
odmówiony.]

Aplikacja firefox próbowała zmienić ochronę dostępu do pamięci (np.
przydzielonej używając malloc). To jest potencjalny problem bezpieczeństwa.
Firefox prawdopodobnie nie jest tu problemem, ale jedna z jego wtyczek. Można
usunąć wtyczkę, a aplikacja nie będzie już wymagała tego dostępu. Jeśli
znana jest wtyczka powodująca żądanie dostępu, proszę otworzyć r

Zezwalanie na dostęp:

Istnieją dwa sposoby naprawienia tego problemu. Można zainstalować pakiet
nsspluginwrapper, który spowoduje uruchomienie przez Firefoksa jego wtyczek w
oddzielnych procesach. Ten proces umożliwi dostęp execmem. Jest to
najbezpieczniejszy wybór. Można także wyłączyć zmienną logiczną
allow_unconfined_nsplugin_transition.
setsebool -P allow_unconfined_nsplugin_transitio

Polecenie naprawy:

yum install nspluginwrapper

Dodatkowe informacje:

Kontekst źródłowy          unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1
                              023
Kontekst docelowy             unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1
                              023
Obiekty docelowe              None [ process ]
Źródło                     firefox
Ścieżka źródłowa         /usr/lib64/firefox-3.6/firefox
Port                          <Nieznane>
Komputer                      (usunięto)
Źródłowe pakiety RPM       firefox-3.6.3-4.fc14
Docelowe pakiety RPM          
Pakiet RPM polityki           selinux-policy-3.8.1-3.fc14
SELinux jest włączony       True
Typ polityki                  targeted
Tryb wymuszania               Enforcing
Nazwa wtyczki                 firefox
Nazwa komputera               (usunięto)
Platforma                     Linux (usunięto) 2.6.34-11.fc14.x86_64 #1
                              SMP Sat May 22 01:03:52 UTC 2010 x86_64 x86_64
Liczba alarmów               6
Po raz pierwszy               nie, 30 maj 2010, 20:46:33
Po raz ostatni                nie, 30 maj 2010, 21:10:52
Lokalny identyfikator         c4aaa0c9-6228-495f-af6b-73e3af89f646
Liczba wierszy                

Surowe komunikaty audytu      

node=(usunięto) type=AVC msg=audit(1275246652.440:23349): avc:  denied  { execmem } for  pid=4982 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=(usunięto) type=SYSCALL msg=audit(1275246652.440:23349): arch=c000003e syscall=10 success=yes exit=4294967424 a0=7fc772fa1000 a1=1000 a2=5 a3=7fffa2b39f70 items=0 ppid=4961 pid=4982 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=4 comm="firefox" exe="/usr/lib64/firefox-3.6/firefox" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)



Hash String generated from  firefox,firefox,unconfined_t,unconfined_t,process,execmem
audit2allow suggests:
Comment 1 Daniel Walsh 2010-06-01 09:47:57 EDT
Are you using any plugins that could be causing this avc?
Comment 2 GoinEasy9 2010-06-02 17:10:26 EDT
I also just got hit with this problem.  Have nspluginwrapper installed, and tried setsebool -P allow_unconfined_nsplugin_transition=0, without success.
Comment 3 GoinEasy9 2010-06-02 17:16:58 EDT
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.
Comment 4 Daniel Walsh 2010-06-03 17:18:37 EDT
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.
Comment 5 GoinEasy9 2010-06-03 22:57:16 EDT
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.
Comment 6 GoinEasy9 2010-06-03 23:04:06 EDT
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
Comment 7 Eric Blake 2010-07-01 19:18:09 EDT
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.
Comment 8 Frank Murphy 2010-07-05 12:00:38 EDT
Same versions as https://bugzilla.redhat.com/show_bug.cgi?id=597858#c7

I have the following addons:
googlesharing
adblock plus
Comment 9 GoinEasy9 2010-07-06 23:30:32 EDT
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.
Comment 10 Jens Petersen 2010-07-13 21:23:35 EDT
I can reproduce after removing nspluginwrapper.
Comment 11 Jens Petersen 2010-07-13 21:27:35 EDT
(Forgive me for translating the summary from Polish to English - sorry but I would almost consider it a setroubleshoot bug.)
Comment 12 Daniel Walsh 2010-07-14 08:37:55 EDT
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.
Comment 13 Frank Murphy 2010-07-22 02:02:15 EDT
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.
Comment 14 Jens Petersen 2010-07-22 23:01:54 EDT
*** Bug 603182 has been marked as a duplicate of this bug. ***
Comment 16 Jens Petersen 2010-07-22 23:36:44 EDT
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.
Comment 17 Adam Williamson 2010-07-23 12:19:54 EDT
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
Comment 18 Matt McCutchen 2010-07-24 22:34:42 EDT
(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.
Comment 19 Adam Williamson 2010-07-26 22:17:32 EDT
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
Comment 20 Adam Williamson 2010-07-26 22:18:14 EDT
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
Comment 21 Jens Petersen 2010-07-27 03:58:18 EDT
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?
Comment 22 Matt McCutchen 2010-07-27 04:07:07 EDT
(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
Comment 23 Matt McCutchen 2010-07-27 04:29:57 EDT
I filed https://fedorahosted.org/fesco/ticket/442 .
Comment 24 Bug Zapper 2010-07-30 07:45:53 EDT
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
Comment 25 Adam Williamson 2010-07-30 12:07:12 EDT
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
Comment 26 James Laska 2010-08-02 11:52:47 EDT
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.
Comment 27 Carl G. 2010-08-02 16:12:41 EDT
*** Bug 608428 has been marked as a duplicate of this bug. ***
Comment 28 Christopher Aillon 2010-08-02 20:30:31 EDT
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.
Comment 29 Matt McCutchen 2010-08-02 23:51:46 EDT
(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.
Comment 30 Daniel Walsh 2010-08-03 14:45:09 EDT
setroubleshoot is launching

/usr/bin/xdg-open

Which should launch the default browser.
Comment 31 Jens Petersen 2010-08-03 21:39:37 EDT
Daniel, I see the avc coming from firefox though.
Is xdg-open another issue?
Comment 32 Frank Murphy 2010-08-04 03:21:23 EDT
This happens in x86_64 for me F14\F15, just notices -all +i686
Comment 33 James Laska 2010-08-04 12:22:33 EDT
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@redhat.com> 3.8.8-9
 - Apply Miroslav munin patch - Turn back on allow_execmem and allow_execmod booleans
Comment 34 James Laska 2010-08-04 12:51:09 EDT
I'm going to remove F14Alpha once we've confirmed that the updated selinux-policy is available and works around this problem.
Comment 35 Daniel Walsh 2010-08-05 13:02:23 EDT
Fixed in selinux-policy-3.8.8-10.fc14.noarch
Comment 36 Fedora Update System 2010-08-05 13:18:41 EDT
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
Comment 37 Adam Williamson 2010-08-05 16:21:43 EDT
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.
Comment 38 Jens Petersen 2010-08-05 22:46:28 EDT
Thanks!  Confirmed, fixed in selinux-policy-3.8.8-10.fc14 on
install of F14 i686 nightly Live.
Comment 39 James Laska 2010-08-06 09:17:54 EDT
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.
Comment 40 Eric Blake 2010-08-06 11:37:09 EDT
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.
Comment 41 Frank Murphy 2010-08-06 11:44:00 EDT
(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
Comment 42 John Poelstra 2010-08-09 09:31:46 EDT
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!
Comment 43 James Laska 2010-08-09 09:35:29 EDT
(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 ?
Comment 44 James Laska 2010-08-09 11:16:23 EDT
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.
Comment 45 Fedora Update System 2010-08-09 14:56:52 EDT
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.
Comment 46 Daniel Walsh 2010-08-10 08:00:49 EDT
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

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