|
|
Java2 security analysis test results, plug-in status and
changes for Eclipse 3.1 (RCP) plug-ins
|
|
|
| Legend |
| Plug-in status |
icon |
| Plug-in secured |
 |
| Plug-in NOT secured |
 |
| No changes required |
 |
| Analysis Tool Completed OK |
 |
| Analysis Tool Failed |
 |
|
|
Java2 security analysis test results, plug-in status and
changes for Eclipse 3.1 (Non-RCP) plug-ins
| Plug-in |
Review status |
Committed to security branch |
Patch |
| org.eclipse.update.core |
100%
|
Yes
|
| org.eclipse.ui.forms |
100%
|
No
|
| org.eclipse.ui.views |
100%
|
N/A
|
org.eclipse.update.core.win32
|
100%
|
N/A
|
org.eclipse.update.ui
|
|
No
|
org.eclipse.core.variables
|
|
No |
org.eclipse.core.resources
|
50%
|
No |
org.eclipse.help.ui
|
|
No |
org.eclipse.help.webapp
|
|
No
|
|
|
| Legend |
| Plug-in status |
icon |
| Plug-in secured |
|
| Plug-in NOT secured |
|
| No changes required |
|
| Analysis Tool Completed OK |
|
| Analysis Tool Failed |
|
|
|
While the analysis tool identifies the locations within the
code where privileges are required, it does not detail how to
appropriately deal with the permission requirement.
There are only 3 options for dealing with a privileged
operation.
- Treat the privileged operation as a trusted
library function. This entails:
- wrapping the privileged operation in a privileged action
- Adding the required permissions to the associated
codebase in the java.policy file.
- Add the required permissions to the .java.policy file.
In this scenario, all classes on the execution stack must have the
required privilege. Any class which does not have the required
permission assignment at runtime will throw a security exception.
- Refactor the code so that option one is viable.
Deciding which approach to take:
Tainted Variables
A privileged operation typically uses parameters, such as
filenames, URLs, usernames, and other inputs. The source of these
inputs can "taint" a call to a privileged operation. Example sources
are method parameters (supplied by caller) and other objects which
return values (e.g. A FileDialog which prompts to the user to supply a
path and filename from the filesystem). This is the "tainted variable"
concept.
A reference trace is required to determine what codebases
(.jar files and classes) ultimately make use of a given method. Eclipse
provides a pop-up menu context when a method is selected, "Open Call
Heirarchy" which provides the required reference trace. SWORD4J
provides a more precise reference trace. To use SWORD4J's callpath
analysis tool, right mouse-click on a permission marker and select "Show callpath".
You would not typically allow a user to read, write, or save a
file from any location in the filesystem if you were trying to protect
data between applications in a framework such as RCP. You would
however, hide the complexities of saving a file so that only the
required file privileges need to be specified. (For example, if your
library implements logging to track changes, this operation is self
contained and could be wrapped in a privileged action so that the
caller does not need both java.io.FilePermission "read,write,delete"
AND java.util.logging.LoggingPermission "control", "").
Method visibility and Access modifiers
There is also the issue of the encapsulating methods's
visibility. If a method is pubic, then any class capable of loading the
class with the privileged operation can call it's methods. Great care
should be taken when implementing a publicly visible trusted library
method to avoid unintentionally elevating the privileges of the caller.
|
