Bug 548267 - nspluginwrapper/plugin-config causing selinux alert
Summary: nspluginwrapper/plugin-config causing selinux alert
Keywords:
Status: CLOSED DUPLICATE of bug 528762
Alias: None
Product: Fedora
Classification: Fedora
Component: nspluginwrapper
Version: 12
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Martin Stransky
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-12-17 02:45 UTC by Deb Mukherjee
Modified: 2018-04-11 18:34 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-03-11 16:51:16 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Deb Mukherjee 2009-12-17 02:45:25 UTC
Description of problem:
I am getting a selinux security alert
*************************************
Summary:

SELinux is preventing /usr/lib64/nspluginwrapper/plugin-config from making the
program stack executable.

Detailed Description:

[plugin-config has a permissive type (unconfined_t). This access was not
denied.]

The plugin-config 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 (http://people.redhat.com/drepper/selinux-mem.html) web page explains how
to remove this requirement. If plugin-config 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.

Allowing Access:

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
plugin-config to run correctly, you can change the context of the executable to
execmem_exec_t. "chcon -t execmem_exec_t
'/usr/lib64/nspluginwrapper/plugin-config'" 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/nspluginwrapper/plugin-config'"

Fix Command:

chcon -t execmem_exec_t '/usr/lib64/nspluginwrapper/plugin-config'

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                        plugin-config
Source Path                   /usr/lib64/nspluginwrapper/plugin-config
Port                          <Unknown>
Host                          badsha
Source RPM Packages           nspluginwrapper-1.3.0-8.fc12
Target RPM Packages           
Policy RPM                    selinux-policy-3.6.32-41.fc12
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Plugin Name                   allow_execstack
Host Name                     badsha
Platform                      Linux badsha 2.6.31.5-127.fc12.x86_64 #1 SMP Sat
                              Nov 7 21:11:14 EST 2009 x86_64 x86_64
Alert Count                   4
First Seen                    Sun 06 Dec 2009 12:41:35 AM EST
Last Seen                     Sun 06 Dec 2009 01:28:47 AM EST
Local ID                      b6a15e15-26df-4285-9b59-1892e0613212
Line Numbers                  

Raw Audit Messages            

node=badsha type=AVC msg=audit(1260080927.349:85): avc:  denied  { execstack } for  pid=8933 comm="plugin-config" 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=badsha type=SYSCALL msg=audit(1260080927.349:85): arch=c000003e syscall=10 success=yes exit=68719476864 a0=7fffbd40b000 a1=1000 a2=1000007 a3=3edca19aeb items=0 ppid=8931 pid=8933 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 ses=1 comm="plugin-config" exe="/usr/lib64/nspluginwrapper/plugin-config" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
*************************************
Seems nspluginwrapper is the culprit
*************************************
This is the confounding part
I do not have nspluginwrapper installed
------------------------------
$ sudo yum remove nspluginwrapper
Loaded plugins: presto, refresh-packagekit
Setting up Remove Process
No Match for argument: nspluginwrapper
Package(s) nspluginwrapper available, but not installed.
No Packages marked for removal
------------------------------
I must say I had installed nspluginwrapper for playing flash- which did not work. I removed it, but looks like it is not cleanly removed and plugin-config is still trying to do something during boot process!
****************************************************
Interestingly:
------------------------------
$ sudo chcon -t execmem_exec_t '/usr/lib64/nspluginwrapper/plugin-config'
chcon: cannot access `/usr/lib64/nspluginwrapper/plugin-config': No such file or directory
------------------------------
Where is this ghost of plugin-config?
****************************************************

Version-Release number of selected component (if applicable):


How reproducible:
got this selinux warning several times in the past 20 days say 10 reboots.

Steps to Reproduce:
1.Reboot and login to gnome.

  
Actual results:
plugin-config is trying to do something when the package should not be there.

Expected results:
Plugin-config should not throw this security alert, actually plugin-config shoul be gone when I remove nspluginwrapper.

Additional info:

Comment 1 Matěj Cepl 2010-03-11 16:51:16 UTC

*** This bug has been marked as a duplicate of bug 528762 ***


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