To illustrate how to analyze Eclipse plug-ins using SWORD4J, we’ll begin by creating a new plug-in project.  Then, we’ll add some privileged code and finally analyze the project granting the required permissions to the plug-in.

Now let's add some privileged code to this plug-in.  

Next, we’ll analyze the plug-in by right mouse clicking on the project in the package Explorer and selecting Security->Analyze from the pop-up context menu.  

The analysis runtime options dialog allows the developer to specify the methods that will be considered entry points in the analysis.  Methods can be selected by access modifiers and individual method signatures.

The output of the analysis is presented in the Analysis view.  Privileged instructions are presented in a hierarchical tree view area.  Double-clicking on a given method signature will open the associated source file in the Java editor. 

Permission markers highlight the privileged source code in the editor window.  

Also note the permissions for the selected method, package, jar, or project are shown in Table view.

The predecessor in the callgraph of the method which requires the selected permission is displayed on the "Required by:" tab.  

Again, by double-clicking on a method signature, the associated source file is opened in the editor window.

To show how a permission propagates from a SecurityManager or AccessController call, select a permission in the permission table and right mouse click on it to select "Show permission propagation" from the pop-up context menu.

The resulting call paths which require the selected permission are displayed in the call paths tree viewer.  

By selecting a given code source in the "Permissions Requirements by CodeSource" tab of the Analysis view, the required granted permission are displayed in the adjacent windows sash. 

By clicking on the security marker in the editor window, a quick fix pop up is available to add required permissions for the associated privileged instructions directly to the OS GI’s permissions.perm file.

This concludes a simple example of identifying a permission requirements in a plug-in into granting them permission to the plug-in by creating a permission entry in the bundle permission file.   

Next, we’ll demonstrate a more complicated example of wrapping privileged instructions in PrivilegedActions.

First a call to a logger utility is added from a project that will be imported into the workspace in the next step.

Now that the logger plug-in project has been imported into the workspace, the DemoPlugin projects manifest needs to add the DemoLogger plug-in as a dependency so that the code becomes visible.

After reorganizing the imports, the compiler error goes away and the DemoPlugin project can be reanalyzed with its new call to the logger utility.

After adding the call to the DemoLogger plug-in, three new permission markers are generated.

A review of the source code reveals that the logger plug-in is attempting to initialize a log file in the state location returned by the eclipse platform, i.e., Bundle.getStateLocation().

To address this problem, we'll wrap the privileged instructions, shown adjacent to the permission markers below, in PrivilegedActions and then reanalyze the plug-in.

Notice that the logger plug-ins init method no longer shows up as a permission requirement for DemoPlugin.  This is due to the fact that the init method is now seen as a trusted library which stops propagation of permission requirements to the client code.

There are essentially three options for mitigating privileged code requirements in a Java program.  First, no code change.  Simply grant the require permissions in the policy file.  This is our first example in this demo.  Second, wrap the associated instructions in a privileged action and grant the required permissions in the Java policy file.  This was our current example.  Finally, you can refactor the code so that permissions do not propagate to the client code.  In this next demonstration we’ll explore this last option.

First, the init() method will be regressed to its original implementation.

Next, the call to init() will be moved from the logEvent method into the plug-ins start() method.

Finally, we’ll reanalyze the plug-in to show that the client no longer requires the permission to create the log file.

Notice that there are no permissions propagating up from the DemoLogger classes and the privileged action wrappers were no longer required.  This is a preferred solution since in this case there is no CPU overhead incurred by invoking the AccessController.doPrivileged() calls.  It is made possible by the architecture of the eclipse framework, namely that the framework startup calls the start() method for a bundle rather than the bundles in the system which may make use of packages exported by a given bundle.