Bug 512845 (gecko-execmem) - setroubleshoot: SELinux is preventing firefox from changing a writable memory segment executable.
Summary: setroubleshoot: SELinux is preventing firefox from changing a writable m...
Keywords:
Status: CLOSED ERRATA
Alias: gecko-execmem
Product: Fedora
Classification: Fedora
Component: xulrunner
Version: rawhide
Hardware: i386
OS: Linux
high
high
Target Milestone: ---
Assignee: Martin Stransky
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: setroubleshoot_trace_hash:23fa895abe9...
: 489097 509945 510950 511877 515198 517998 521191 523847 524088 524354 524374 524382 524427 524441 524693 525265 525279 525399 525550 (view as bug list)
Depends On:
Blocks: 597858
TreeView+ depends on / blocked
 
Reported: 2009-07-20 23:17 UTC by Steven Usdansky
Modified: 2018-04-11 07:48 UTC (History)
48 users (show)

Fixed In Version: selinux-policy-3.8.8-10.fc14
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-08-09 18:57:01 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Mozilla Foundation 506693 0 None None None Never

Description Steven Usdansky 2009-07-20 23:17:01 UTC
The following was filed automatically by setroubleshoot:

Summary:

SELinux is preventing firefox from changing a writable memory segment
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.
Applications should not be doing this. Applications are sometimes coded
incorrectly and request this permission. The SELinux Memory Protection Tests
(http://people.redhat.com/drepper/selinux-mem.html) web page explains how to
remove this requirement. If firefox 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 bug report
(http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package.

Allowing Access:

If you trust firefox to run correctly, you can change the context of the
executable to execmem_exec_t. "chcon -t execmem_exec_t
'/usr/lib/firefox-3.5/firefox'". You must also change the default file context
files on the system in order to preserve them even on a full relabel. "semanage
fcontext -a -t execmem_exec_t '/usr/lib/firefox-3.5/firefox'"

Fix Command:

chcon -t execmem_exec_t '/usr/lib/firefox-3.5/firefox'

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.5/firefox
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           firefox-3.5-2.fc12
Target RPM Packages           
Policy RPM                    selinux-policy-3.6.21-3.fc12
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   allow_execmem
Host Name                     (removed)
Platform                      Linux (removed)
                              2.6.31-0.67.rc2.git9.fc12.i586 #1 SMP Mon Jul 13
                              11:40:35 EDT 2009 i686 i686
Alert Count                   5
First Seen                    Mon 20 Jul 2009 06:15:26 PM EDT
Last Seen                     Mon 20 Jul 2009 06:16:28 PM EDT
Local ID                      e94e6d29-1c0c-4149-a0da-ce7d684a1e2c
Line Numbers                  

Raw Audit Messages            

node=(removed) type=AVC msg=audit(1248128188.596:66): avc:  denied  { execmem } for  pid=2086 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=(removed) type=SYSCALL msg=audit(1248128188.596:66): arch=40000003 syscall=192 success=no exit=-13 a0=0 a1=1000 a2=7 a3=22 items=0 ppid=2074 pid=2086 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.5/firefox" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)


audit2allow suggests:

#============= unconfined_t ==============
allow unconfined_t self:process execmem;

Comment 1 Matěj Cepl 2009-07-21 20:33:24 UTC
What did you to get this AVC denial message?

Comment 2 Steven Usdansky 2009-07-22 02:03:33 UTC
1. Set selinux to enforcing mode
2. Run firefox
3. Click on a button in my Bookmarks Toolbar

Note: I updated earlier today to today's Rawhide, and I'm not getting any messages from selinux (probably because I turned off sealert), but firefox is still aborting if I do the above.

Comment 3 Matěj Cepl 2009-07-22 13:05:04 UTC
*** Bug 511877 has been marked as a duplicate of this bug. ***

Comment 4 Matěj Cepl 2009-07-22 13:06:14 UTC
Yes, can reproduce and this makes Firefox unusable with SELinux Enforcing.

Comment 5 Lubomir Rintel 2009-07-22 13:34:25 UTC
(In reply to comment #4)
> Yes, can reproduce and this makes Firefox unusable with SELinux Enforcing.  

Indeed it is. Why on earth is this bug flagged as security sensitive?

Comment 6 Lubomir Rintel 2009-07-22 13:35:07 UTC
Whoops, sorry, wrong bug.

Comment 7 Matěj Cepl 2009-07-22 15:11:26 UTC
*** Bug 509945 has been marked as a duplicate of this bug. ***

Comment 8 Matěj Cepl 2009-07-22 15:17:14 UTC
(In reply to comment #4)
> Yes, can reproduce and this makes Firefox unusable with SELinux Enforcing.  

and yes, I can reproduce with ftp://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-1.9.1/firefox-3.5.2pre.en-US.linux-i686.tar.bz2 (although interestingly not with x86_64, both ours and upstream binary).

Comment 9 Colin Walters 2009-07-22 17:18:16 UTC
Probably because x86_64 doesn't have a JIT yet.

Comment 10 Matěj Cepl 2009-07-23 13:54:29 UTC
(In reply to comment #9)
> Probably because x86_64 doesn't have a JIT yet.  

/me feels like an idiot

Comment 11 Nicolas Mailhot 2009-08-02 11:53:48 UTC
(In reply to comment #8)

> (although interestingly not with x86_64, both ours and upstream binary).  

Well I get AVCs all the time on an x86_64 system (some web sites like http://www.expe.fr/ seem very crash-happy)

firefox-00:3.5.1-3.fc12.x86_64

swfdec-00:0.9.2-3.fc12.x86_64
swfdec-gtk-00:0.9.2-3.fc12.x86_64
swfdec-mozilla-00:0.9.2-3.fc12.x86_64

Résumé
SELinux is preventing firefox from making the program stack executable. 

Description détaillée
The firefox application attempted to make its stack executable. This is a potential security problem. This should never ever be necessary. Stack memory is not executable on most OSes these days and this will not change. Executable stack memory is one of the biggest security problems. An execstack error might in fact be most likely raised by malicious code. Applications are sometimes coded incorrectly and request this permission. The SELinux Memory Protection Tests web page explains how to remove this requirement. If firefox 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 bug report against this package.

Autoriser l'accès
Sometimes a library is accidentally marked with the execstack flag, if you find a library with this flag you can clear it with the execstack -c LIBRARY_PATH. Then retry your application. If the app continues to not work, you can turn the flag back on with execstack -s LIBRARY_PATH. Otherwise, if you trust firefox to run correctly, you can change the context of the executable to execmem_exec_t. "chcon -t execmem_exec_t '/usr/lib64/firefox-3.5.1/firefox'" You must also change the default file context files on the system in order to preserve them even on a full relabel. "semanage fcontext -a -t execmem_exec_t '/usr/lib64/firefox-3.5.1/firefox'"

Commande de correction
chcon -t execmem_exec_t '/usr/lib64/firefox-3.5.1/firefox'

Informations complémentaires
Contexte source:  unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
Contexte cible:  unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
Objets du contexte:  None [ process ]
source:  firefox
Chemin de la source:  /usr/lib64/firefox-3.5.1/firefox
Port:  <Inconnu>
Hôte:  
Paquetages RPM source:  firefox-3.5.1-3.fc12
Paquetages RPM cible:  
Politique RPM:  selinux-policy-3.6.26-2.fc12
Selinux activé:  True
Type de politique:  targeted
MLS activé:  True
Mode strict:  Enforcing
Nom du plugin:  allow_execstack
Nom de l'hôte:  
Plateforme:  Linux  2.6.31-0.117.rc5.kbz13551.fc12.x86_64 #1 SMP Sat Aug 1 07:04:15 EDT 2009 x86_64 x86_64
Compteur d'alertes:  2
Première alerte:  dim. 02 août 2009 13:47:24 CEST
Dernière alerte:  dim. 02 août 2009 13:47:24 CEST
ID local:  21b15c64-bd91-4a1f-a45e-c5dc283c000fNuméros des lignes:  

Messages d'audit bruts :
node= type=AVC msg=audit(1249213644.54:35225): avc: denied { execstack } for pid=13257 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= type=SYSCALL msg=audit(1249213644.54:35225): arch=c000003e syscall=10 success=yes exit=0 a0=7fff17c28000 a1=1000 a2=1000007 a3=7f21f51e8979 items=0 ppid=13229 pid=13257 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/lib64/firefox-3.5.1/firefox" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)

Comment 12 Nicolas Mailhot 2009-08-02 11:56:16 UTC
(for some reason setroubleshoot insists it's the same as bug #509496)

Comment 13 Lubomir Rintel 2009-08-04 12:01:05 UTC
So, what's going on with this? Shouldn't we disable JIT compiler in rawhide now; non-working firefox considerably impairs its usability.

Comment 15 Christopher Aillon 2009-08-07 17:41:00 UTC
This is filed as https://bugzilla.mozilla.org/show_bug.cgi?id=506693 upstream, which is marked security sensitive.  Marking security sensitive until that is made public.

Comment 16 Bill Nottingham 2009-08-07 19:40:31 UTC
'Fixed' in selinux-policy-3.6.26-8.fc12 by relaxing the execstack setting. This will need revisited in the future...

Note that after installing the package, you may need to reboot, or temporarily set the allow_execstack boolean until you reboot.

Comment 17 Jesse Keating 2009-08-07 20:04:45 UTC
Tagged for alpha, closing this bug.

Comment 18 Christopher Aillon 2009-08-07 20:36:03 UTC
Eep.  I'd really like to keep this open until it's properly fixed.... Especially since this is on the F12 blocker list, too for fixing it for reals.

Comment 19 Jesse Keating 2009-08-07 21:33:30 UTC
Dropping it from the Alpha tracker then.

Comment 20 Tomas Hoger 2009-08-10 09:46:45 UTC
(In reply to comment #15)
> This is filed as https://bugzilla.mozilla.org/show_bug.cgi?id=506693 upstream,
> which is marked security sensitive.  Marking security sensitive until that is
> made public.

Upstream bug is public, so making this public too.

Comment 21 Christopher Aillon 2009-08-12 18:55:50 UTC
*** Bug 515198 has been marked as a duplicate of this bug. ***

Comment 22 Eric Paris 2009-08-18 13:39:07 UTC
*** Bug 517998 has been marked as a duplicate of this bug. ***

Comment 23 John Brier 2009-09-17 14:26:25 UTC
I just ran into this on F12 alpha after updating yesterday:



[root@cam firefox]# sealert -l 614154dd-b01a-47cc-8a01-2beeedf8dcef

Summary:

SELinux is preventing /usr/lib/firefox-3.5.3/firefox from changing a writable
memory segment 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.
Applications should not be doing this. Applications are sometimes coded
incorrectly and request this permission. The SELinux Memory Protection Tests
(http://people.redhat.com/drepper/selinux-mem.html) web page explains how to
remove this requirement. If firefox 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 bug report against this package.

Allowing Access:

If you trust firefox to run correctly, you can change the context of the
executable to execmem_exec_t. "chcon -t execmem_exec_t
'/usr/lib/firefox-3.5.3/firefox'". You must also change the default file context
files on the system in order to preserve them even on a full relabel. "semanage
fcontext -a -t execmem_exec_t '/usr/lib/firefox-3.5.3/firefox'"

Fix Command:

chcon -t execmem_exec_t '/usr/lib/firefox-3.5.3/firefox'

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.5.2/firefox
Port                          <Unknown>
Host                          cam.usersys.redhat.com
Source RPM Packages           firefox-3.5.3-1.fc12
Target RPM Packages           
Policy RPM                    selinux-policy-3.6.31-5.fc12
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   allow_execmem
Host Name                     cam.usersys.redhat.com
Platform                      Linux cam.usersys.redhat.com
                              2.6.31-14.fc12.i686.PAE #1 SMP Tue Sep 15 03:49:03
                              EDT 2009 i686 i686
Alert Count                   377
First Seen                    Mon Sep  7 11:04:59 2009
Last Seen                     Thu Sep 17 10:08:44 2009
Local ID                      614154dd-b01a-47cc-8a01-2beeedf8dcef
Line Numbers                  

Raw Audit Messages            

node=cam.usersys.redhat.com type=AVC msg=audit(1253196524.952:532): avc:  denied  { execmem } for  pid=23936 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=cam.usersys.redhat.com type=SYSCALL msg=audit(1253196524.952:532): arch=40000003 syscall=192 success=no exit=-13 a0=0 a1=2000 a2=7 a3=22 items=0 ppid=23921 pid=23936 auid=500 uid=500 gid=501 euid=500 suid=500 fsuid=500 egid=501 sgid=501 fsgid=501 tty=pts1 ses=1 comm="firefox" exe="/usr/lib/firefox-3.5.3/firefox" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)


It seems to affect galeon in the same way

[root@cam firefox]# sealert -l 614154dd-b01a-47cc-8a01-2beeedf8dcef

Summary:

SELinux is preventing /usr/bin/galeon from changing a writable memory segment
executable.

Detailed Description:

The galeon application attempted to change the access protection of memory
(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 SELinux Memory Protection Tests
(http://people.redhat.com/drepper/selinux-mem.html) web page explains how to
remove this requirement. If galeon 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 bug report against this package.

Allowing Access:

If you trust galeon to run correctly, you can change the context of the
executable to execmem_exec_t. "chcon -t execmem_exec_t '/usr/bin/galeon'". You
must also change the default file context files on the system in order to
preserve them even on a full relabel. "semanage fcontext -a -t execmem_exec_t
'/usr/bin/galeon'"

Fix Command:

chcon -t execmem_exec_t '/usr/bin/galeon'

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.5.2/firefox
Port                          <Unknown>
Host                          cam.usersys.redhat.com
Source RPM Packages           galeon-2.0.7-14.fc11
Target RPM Packages           
Policy RPM                    selinux-policy-3.6.31-5.fc12
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   allow_execmem
Host Name                     cam.usersys.redhat.com
Platform                      Linux cam.usersys.redhat.com
                              2.6.31-14.fc12.i686.PAE #1 SMP Tue Sep 15 03:49:03
                              EDT 2009 i686 i686
Alert Count                   369
First Seen                    Mon Sep  7 11:04:59 2009
Last Seen                     Thu Sep 17 10:03:31 2009
Local ID                      614154dd-b01a-47cc-8a01-2beeedf8dcef
Line Numbers                  

Raw Audit Messages            

node=cam.usersys.redhat.com type=AVC msg=audit(1253196211.977:523): avc:  denied  { execmem } for  pid=23876 comm="galeon" 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=cam.usersys.redhat.com type=SYSCALL msg=audit(1253196211.977:523): arch=40000003 syscall=192 success=no exit=-13 a0=0 a1=2000 a2=7 a3=22 items=0 ppid=2170 pid=23876 auid=500 uid=500 gid=501 euid=500 suid=500 fsuid=500 egid=501 sgid=501 fsgid=501 tty=pts1 ses=1 comm="galeon" exe="/usr/bin/galeon" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)

Comment 24 Will Woods 2009-09-21 18:03:53 UTC
*** Bug 524374 has been marked as a duplicate of this bug. ***

Comment 25 Daniel Walsh 2009-09-22 02:50:27 UTC
*** Bug 524693 has been marked as a duplicate of this bug. ***

Comment 26 Matěj Cepl 2009-09-22 16:26:58 UTC
*** Bug 524441 has been marked as a duplicate of this bug. ***

Comment 27 Matěj Cepl 2009-09-22 16:27:43 UTC
*** Bug 524427 has been marked as a duplicate of this bug. ***

Comment 28 Matěj Cepl 2009-09-22 16:28:39 UTC
*** Bug 524382 has been marked as a duplicate of this bug. ***

Comment 29 Matěj Cepl 2009-09-22 16:29:53 UTC
*** Bug 524354 has been marked as a duplicate of this bug. ***

Comment 30 Matěj Cepl 2009-09-22 16:30:22 UTC
*** Bug 524088 has been marked as a duplicate of this bug. ***

Comment 31 Matěj Cepl 2009-09-22 16:30:52 UTC
*** Bug 523847 has been marked as a duplicate of this bug. ***

Comment 32 Matěj Cepl 2009-09-22 16:32:21 UTC
*** Bug 521191 has been marked as a duplicate of this bug. ***

Comment 33 Matěj Cepl 2009-09-23 21:46:49 UTC
*** Bug 525265 has been marked as a duplicate of this bug. ***

Comment 34 Matěj Cepl 2009-09-23 21:47:48 UTC
*** Bug 525279 has been marked as a duplicate of this bug. ***

Comment 35 Matěj Cepl 2009-09-24 09:29:00 UTC
*** Bug 525399 has been marked as a duplicate of this bug. ***

Comment 36 Matěj Cepl 2009-09-24 21:59:18 UTC
*** Bug 525550 has been marked as a duplicate of this bug. ***

Comment 37 Christopher Aillon 2009-09-28 18:42:59 UTC
*** Bug 510950 has been marked as a duplicate of this bug. ***

Comment 38 Martin Stransky 2009-09-29 10:46:34 UTC
*** Bug 489097 has been marked as a duplicate of this bug. ***

Comment 39 Martin Stransky 2009-10-06 13:47:43 UTC
(In reply to comment #14)
> http://people.redhat.com/drepper/selinux-mem.html
> http://gcc.gnu.org/viewcvs/trunk/libffi/src/closures.c?revision=150042&view=markup
> 
> for examples.  

BTW. who maintains this code? There's a bug there... getmntent_r() returns NULL for failures but the code throws error when a valid pointer is returned...so the mount point is not searched.

Comment 40 Harald Hoyer 2009-10-15 12:13:01 UTC
any updates?

Comment 41 Kjartan Maraas 2009-10-15 12:24:57 UTC
Haven't seen this in a while.

Comment 42 Tim Lauridsen 2009-10-15 13:40:59 UTC
Don't look we are hit by this in current rawhide, because the current selinux policy is relaxing on the the execstack setting.

Comment 43 Daniel Walsh 2009-10-15 14:20:57 UTC
Current F12 Beta settings

getsebool -a | grep allow_exec
allow_execheap --> off
allow_execmem --> off
allow_execmod --> off
allow_execstack --> off

This means no application executed by the unconfined_t user is allow to have execmem and freinds permission, unless it is labeled execmem_exec_t, java_exec_t, wine_exec_t, or mono_exec_t

mozilla_exec_t will execute as unconfined_execmem_t iff allow_unconfined_nsplugin_transition boolean is off, which in beta right now is off.

getsebool -a | grep nsplugin_transition
allow_unconfined_nsplugin_transition --> off

I plan on turning on allow_execmem on for Final release, since there are two many badly written apps still.   :^(

Comment 44 Jesse Keating 2009-10-21 23:20:47 UTC
Has this been turned on yet?  This is the final stretch when we need to know if things are working.

Comment 45 Daniel Walsh 2009-10-22 15:07:18 UTC
Yes it is on as of -27.  It does not effect upgrades though, only fresh installs.


We do not change the state of booleans on upgrades.

Comment 46 Jesse Keating 2009-10-22 17:48:14 UTC
Ok, then I'm at least moving this bug off the tracker, not sure if it should be closed or not.

Comment 47 Daniel Walsh 2009-10-22 19:01:13 UTC
No it should not be closed.  But it and all of the bugs that block execmem are no longer blockers.

Comment 48 Colin Walters 2009-10-22 19:26:50 UTC
(In reply to comment #45)
> Yes it is on as of -27.  It does not effect upgrades though, only fresh
> installs.
> 
> 
> We do not change the state of booleans on upgrades.  

Hmm, so that means if I have F11 installed and then I click on the upgrade button to F12, I will start getting setroubleshoot popups about firefox?

Comment 49 Daniel Walsh 2009-10-22 19:40:06 UTC
No because in F11 the default was allow_execmem.

I only turn allow_execmem off for the testers of Rawhide.

Comment 50 Bug Zapper 2009-11-16 11:02:36 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

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

Comment 52 Matěj Cepl 2010-03-11 16:57:08 UTC
strictly speaking, this is probably duplicate of bug 528762, but not 100% certain about it

Comment 53 Fedora Update System 2010-08-05 17:18:30 UTC
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 54 Jens Petersen 2010-08-06 02:50:44 UTC
Thanks selinux-policy-3.8.8-10.fc14 works around the problem for F14 (i686)
but maybe this bug should be kept open to track the upstream issue?

Comment 56 Fedora Update System 2010-08-09 18:56:43 UTC
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.


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