|JavaTM 2 Permission Analysis|
Prior to deploying application or library code in Java, an important question arises: “What Java Permissions are required to enable the code to run in a system which has the security authorization subsystem enabled?” Currently, this problem is solved empirically. The code writer reads the documentation for any libraries (including the Java runtime libraries) invoked by the code and determines whether any of these libraries requires that the code have specific Permissions in order to run. Unfortunately, this documentation is often missing or out of date. In the absence of reliable documentation, the developer runs the new code and waits until a SecurityException is thrown due to an insufficient set of Permissions allocated to the new code. The developer then adds any additional required Permissions to the set granted to the code under test. This trial-and-error process is repeated (possibly many times) until no more SecurityException failures occur. However, it is possible that some of the Permissions necessary to run the code for particular input data are not discovered at this testing stage, which potentially makes final products unstable.
An analogous scenario can be depicted on a system where mobile code is dynamically installed. When mobile code is downloaded on a system, the system administrator (e.g., the Web browser user) must determine which Permissions code needs in order for it to work without causing SecurityException failures. The system administrator must therefore rely on the code developers’/distributors’ recommendations, with the risk that too many Permissions are granted and security holes are opened. Alternatively, the system administrator must first run the code with no Permissions, look at the SecurityExceptions thrown, and incrementally grant Permissions as is necessary. This process can be tedious and error-prone. As before, insufficient code testing may result in a wrong set of Permissions being granted, which may open security exposures or application instability.
Rather than relying on empirical, or ad hoc, methods of determining what Permissions are required to run application/library code, we have developed a process by which the required Permissions for a software component (e.g., library, application, etc.) can be computed statically.
An example of the output of the analysis can be found here. This analysis is of a program called CountMain, which has a structure that can be seen in this jpg file. Here is the source code for CountMain, CountFileCaller1, CountFileCaller2, CountFile1 and CountFile2. Our Permission analysis tool automatically produces also a list of Permission requirements by class as well as a policy file that would allow the application to run when the default SecurityManager is installed.
A paper discribing this work can be found here.
The analysis described here is based on our control flow and data flow analysis work. You can return to our home page.