Generating security permissions

Embodiments of the invention relate to generating security permissions for applications. A static analysis on an application is carried out to determine security exceptions and to determine the application components responsible for the security exceptions. The determined security exceptions are analyzed to calculate permissions required for each component. A security policy file that includes a hierarchy of the required permissions suitable for the type of application is formatted and applied to the application to provide a security enabled application.

PRIORITY

The present application claims priority to European Patent Application No. 11180574.3, filed on Sep. 8, 2011, and all the benefits accruing therefrom under 35 U.S.C. §119, the contents of which in its entirety are herein incorporated by reference.

BACKGROUND

This present invention relates generally to the field of security permissions for applications, and more specifically, to generating security permissions for applications in an enterprise environment.

Java 2 Security is a fine-grained, policy-based access control mechanism that is intended to increase overall system integrity by guarding access to protected system resources. (Java and ail Java-based trademarks and logo are trademarks or registered trademarks of Oracle and/or its affiliates.)

A typical scenario that occurs when Java 2 Security is enabled is that applications will stop working due to security access exceptions. The system administrator has to set up a coherent security policy, and this requires experience and security expertise on the part of the system administrator. An alternative option is to allow users to handle the policy management, which may result in mistakes being made due to their lack of expertise in defining security policies.

In many cases, in order to get applications working quickly, applications are given the permission “AllPermission” which is all encompassing and essentially negates the value that Java 2 Security is intended to provide.

Once the application is working, the tendency is not to go back to define proper security settings. System users may have a misplaced sense of security and assume that they have security protection as they know that Java 2 Security is enabled on the server.

Users that attempt to define the correct policy for their files may encounter difficulties. Often it is recommended that the application code be executed and that each time a security exception is hit, the security exception is analysed. Examples of options that may be taken when a security exception is encountered include: put the code in a “doPrivileged” block if the code is trusted (a drawback to this option is that this will open security holes); add the exception to the security policy file; and recode the application if the application should not actually be using that code.

The decision of which option to take requires a good understanding of security and of the application code. Once users have decided which option to take, they rerun the application again and potentially hit the next security exception and repeat the process until the application runs cleanly. Even once the application has run cleanly there is no guarantee that all the code paths which might generate a security exception will have been exercised, so it may just be a matter of time before the user hits the next one.

Adding to the difficulty of defining a security policy is that enterprise applications are often made up of multiple components. In the case of Java Enterprise Edition (EE) Enterprise Archive (EAR) files, the components might include, for example, Java Archive (JAR) files or Web application Archive (WAR) files contained in a hierarchy. Similarly, for OSGi Enterprise Bundle Archive (EBA) enterprise applications, the components might consist of different bundles in a hierarchy. (OSGi is a trademark or a registered trademark of the OSGi Alliance in the United States, other countries, or both.) Java 2 Security can be defined hierarchically to allow policies to be fine-tuned to the separate components. To add to the complication, the way these are defined for the different enterprise applications is different as well. In addition, the format of these policies is extremely sensitive to incorrect formatting, and they are of slightly different formats for each type of enterprise application.

SUMMARY

Embodiments include a method, system, and computer program product for generating security permissions for applications. A static analysis on an application is carried out to determine security exceptions and to determine the application components responsible for the security exceptions. The determined security exceptions are analysed to calculate permissions required for each component. A security policy file that includes a hierarchy of the required permissions suitable for the type of application is formatted and applied to the application to provide a security enabled application.

DETAILED DESCRIPTION

A method and system are described in which a tool is provided which a user may run once, which calculates the possible security exceptions in an application and the components they correspond to. The user may then confirm if all of these exceptions are valid, so that the tool proceeds and produces required security policy files in the correct format. Furthermore, the required security policy files are calculated correctly to match the application hierarchy, which enables their application for Java 2 Security.

The described method and system takes an application and, through static analysis of the application components, produces the set of required Java 2 Security permissions that the application requires in order to run.

There are two stages to the described process.

First, a permission analysing stage takes an existing application which may be in an enterprise environment (for example, an OSGi or Java EE), and performs a static analysis of the code to calculate what security access exceptions might be generated by the code, and which components of the application would be generating those security access exceptions. Analysis of the results then calculates what permissions should be allocated to each component.

Second, a permission formatting stage takes as input the original application and the output from the permission analysis to produce a final application with the correct Java 2 Security permission or policy files. This stage determines the type of application and from there it determines the correct structure of the file(s) and determines the correct way to represent the hierarchy of permissions. In JEE this may be one high-level file, with corresponding entries for the component codebases. For OSGi, it may be one high-level application level permission file, as well as component level permission files packaged up inside the bundles themselves.

The use of static analysis techniques generates secured applications, with only minimal validation required by a system administrator before deployment, whereby the permission structure also correctly reflects the code hierarchy of the application components.

Referring toFIG. 1, a block diagram shows an embodiment of the system100in accordance with an embodiment. A security permission tool110is provided for generating and applying security permissions to an application101.

The security permission tool110shown inFIG. 1includes two main components providing two stages. A first component is a permission analyser component120. The second component is a permission formatting component130.

The permission analyser component120shown inFIG. 1also includes an application input component121for receiving an application101to be analysed. In an embodiment, a static analysis component122is provided for performing static analysis of the code of the application101. The static analysis component122outputs security access exceptions123which are mapped to references124of components102of the application101generating the exceptions123. A permission generating component125is provided for calculating the permissions126which should be allocated to each component102of the application101.

The permission formatting component130shown inFIG. 1includes an input component131for receiving the application101and the permissions126generated by the permission analyser component120. In an embodiment, the permissions126map to the references124of components102of the application101.

The permission formatting component130shown inFIG. 1also includes an application identifying component132for determining the type and structure and hierarchy of the application101. A hierarchical component136is provided for generating a hierarchical tree based on the structure of the application and permissions required.

In the embodiment shown inFIG. 1, a formatting component133formats the permissions126in a correct form of security policy for the type of application including hierarchy of the permissions126to generate a formatted policy file134.

As shown inFIG. 1, a constraints component137may also be provided with given policy constraints for an application to be compared against generated security policies.

As shown in the embodiment inFIG. 1, an application formatting component135is provided for applying the formatted policy file134to the application101to produce a security enabled application103. The permission formatting component130outputs the security enabled application103including the correctly formatted permissions and security policies applied to the application components102.

There are known tools that can detect potential areas of code that would generate a security exception. For example, FindBugs (FindBugs is a trade mark of University of Maryland) is an open source example of a tool which may be run as part of a build process to statically analyse code. The standard use of this is to warn developers of areas which might potentially need to be encapsulated in a doPriviledged block. Embodiments described herein make use of such existing static analysis methods to calculate all the possible security exceptions that the application code could generate, and therefore the corresponding maximal set of permissions needed.

As well as storing the permissions, the system may also keep a mapping of which component required the permissions.

By performing set calculations, it is possible to determine which permissions can be extracted out to a higher level, and which would only be needed by particular components. In this way, the permission structure generated will still be kept as closely tied to the component hierarchy as possible. The benefit of this is that it avoids the situation where permissions are granted at the application level unnecessarily making the system less secure when only a small component of the application needs to be granted that permission.

Referring toFIG. 2, an exemplary system for implementing aspects of embodiments of the invention includes a data processing system200suitable for storing and/or executing program code including at least one processor201coupled directly or indirectly to memory elements through a system bus203. The memory elements may include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.

In the embodiment inFIG. 2, the memory elements include system memory202in the form of read only memory (ROM)204and random access memory (RAM)205. A basic input/output system (BIOS)206may be stored in ROM204. System software207may be stored in RAM205including operating system software208including operating system (OS)209. Software applications210may also be stored in RAM205.

The system200may also include a primary storage means211such as a magnetic hard disk drive and secondary storage means212such as a magnetic disc drive and an optical disc drive. The drives and their associated computer-readable media provide non-volatile storage of computer-executable instructions, data structures, program modules and other data for the system200. Software applications may be stored on the primary and secondary storage means211,212as well as the system memory202.

The computing system200may operate in a networked environment using logical connections to one or more remote computers via a network adapter216.

Input/output devices213can be coupled to the system either directly or through intervening I/O controllers. A user may enter commands and information into the system200through input devices such as a keyboard, pointing device, or other input devices (for example, microphone, joy stick, game pad, satellite dish, scanner, or the like). Output devices may include speakers, printers, etc. A display device214is also connected to system bus203via an interface, such as video adapter215.

Referring toFIG. 3, a flow diagram300of a method that may be implemented by an embodiment is generally shown. This diagram shows the flow of how an application becomes a Java 2 Security ready application in accordance with an embodiment.

An application is input at block301into the system. A static analysis is carried out at block302on the application to analyze code for potential security exceptions. The code fragments are listed at block303with their associated security exceptions. For each code fragment in the listing, the code fragment is analyzed at block304to ascertain the required parameters for the security policy and to calculate permissions required. For example, for a code fragment that writes to disk that requires a FilePermission, it is ascertained that it is a “write” call and the associated file is written to from the method signature.

Security policy files are formatted and a hierarchical tree is generated at block305based on the code's class structure (inheritance, etc.) with each node being the associated security policy for that particular component/class.

The security policies are aggregated by determining, at block306, if for any node, all its descendants have a given specific security policy. If so, at block307, this policy is removed from each descendant and added it to the node's security policy.

The generated security policies are compared at block308to the given policy constraints provided to the generating application. If none match, then it is assumed appropriate and correct security policy definitions have been generated and processing continues at block310. If a match is found, then a user is alerted at block309and the violating security policy is removed from the generated security policy definition.

At block311, based on the security policy definitions generated, the appropriate security policy files are generated and the security policy files are then applied in the format of the determined hierarchy for the application and a security enabled application is generated311.

Using the above method, when generating the security policy for a given piece of code, the policy generation application described has the ability to be able to specify constraints. A default set of policy constraints may be specified for the policy generation such that if a generated policy violates any of these constraints, it would flag the user, otherwise it would assume that all is correct.

For example, a constraint may be that no application can write to the root directory of a file system. By specifying this constraint, if a policy is targeted to be generated that allows write permission to a root directory then this would be flagged to the user and not included in any generated security policy file.

Referring toFIGS. 4A and 4B, an example embodiment is illustrated.

FIG. 4Awalks through an example of a first stage of analyzing permissions in accordance with an embodiment. An enterprise application is analysed to calculate the full set of permissions that might be needed by the application at runtime.

An application400includes a first component A401and a second component B402. A permission analyser component420analyses the application400. It is determined that two permissions441,442are required by the first component A401and three permissions451,452,453are required by the second component B402. It is noted that permission441and permission451are the same permission that is needed by both component A401and component B402. This permission441,451is pulled up to the application level of a permission hierarchy460. The rest of the permissions are kept linked to the particular components they have been generated from.

FIG. 4Billustrates the second phase of the process where the calculated permissions fromFIG. 4Aare used to produce and package the final security enabled application, according to the requirements of the type of application.

InFIG. 4B, two types of application are handled by a permission formatting component430. The type of application will determine the permission file structure within the application, naming of the files and also syntax of the permissions within the file.

A first application400A is shown as an example OSGi enterprise application. Three permission policy files471,472,473are generated for the OSGi enterprise application for each of the first application400A, component A401A and component B402A.

A second application400B is shown in the form of an example Java enterprise application with component A401B and component B402B. For this form of application a single permission policy file480may be generated with the component hierarchy specified within that file.

In this form of second application400B, the component hierarchy may be specified as:

The described method and system address the problem of an incorrectly configured or a non-existent security policy for executing an application. Embodiments of the invention involve static analysis of an application to determine security exposures and to formulate an appropriate security policy for proposal to a system user/administrator. In this way, secure applications can be prepared for execution without undue burden on system administrators who may know nothing of either or both of enterprise security or the particular application.

A system for generating security permission for an application may be provided as a service to a customer over a network.