doi:10.1016/j.cose.2004.08.006 
Copyright © 2004 Elsevier Ltd All rights reserved.
Performance of the Java security manager
Department of Computer and Information Science, Linköping University, 581 83 Linkoping, Sweden
Received 7 April 2004;
revised 11 August 2004;
accepted 18 August 2004.
Available online 17 November 2004.
References and further reading may be available for this article. To view references and further reading you must
purchase this article.
Abstract
The Java Security Manager is one major security feature of the Java programming language. However, in many Java applications the Security Manager is not enabled because it slows execution time. This paper explores the performance of the Java Security Manager in depth, identifies the permissions with the worst performance and gives advice on how to use the Security Manager in a more efficient way.
Our performance test shows that the CPU execution time penalty varies between 5% and 100% per resource access statement. This extreme range is due to the fact that some resource accesses are costly (such as file and socket access) and therefore hide the performance penalty for the access control check almost completely. The time penalty is much more noticeable with access to main memory resources (such as Java objects).
In order to achieve reasonable response times, it is of utmost importance to tune garbage collection because the Java Security Manager creates short-lived objects during its permission check. Also, the order of permissions in the policy file can be important.
Keywords: Java; Performance; Security; Security Manager; Access controller; Permission; Policy; CPU execution time
Figure 1. Java security architecture. The bytecode verifier checks the validity of Java class files. The class loader finds needed classes. The security manager wraps the access controller that decides whether user code has access to protected resources or not. The decision is based on the contents of the policy file. Signed user code is authenticated by the access controller using the security package and the key database.
Figure 2. Java code for accessing the protected resource of a system property.
Figure 3. Call chain for checking access to system properties.
Figure 4. Typical Java policy file with one set of permissions for the code base at /sw/jars/example1.jar and full permissions for all code signed by bob.
Figure 5. Typical performance for policy access containing a constant CPU consumer method for Solaris (left) and Linux (right). An AllPermission performs fastest of all permissions. Exact match and wildcard match are approximately equal. Enorm-exact contains other exact security permissions and is slightly slower. Worst is the exact match in a policy file with 54 code bases and 4521 permissions due to the high startup penalty. Note the remarkable difference of factor 5 for the absolute execution times between the two platforms. The more erratic curve for Linux may come from the higher resolution of its y-axis and/or from the shorter execution times that may be more difficult to measure with good precision.
Figure 6. Call chain for system property access with AllPermission policy.
Figure 7. Part of a policy file with SocketPermissions. Full host names such as www.google.com are resolved to check if they result in the same IP-address as the needed permission.
Table 1.
Memory allocation in bytes for one resource access with and without Security Manager (SM) and with different policies
The policy check on the top row of the table shows the minimum memory consumption for the Security Manager consisting of allocations for an access control context object and a protection domain object. Any startup memory penalty is omitted. Only objects relevant to the Security Manager are shown in the column Allocated Objects. Numbers in italics indicate that memory is allocated per protection domain.
Table 2.
References to SocketPermission problems in the Java bug database at http://developer.java.sun.com/developer/bugParade/
Table 3.
CPU execution times in milliseconds on the Solaris operating system for checking different BasicPermissions (AWTPermission, RuntimePermission, PropertyPermission, DelegationPermission) including the time used for running a control loop
Note that a delegation permission does not support wildcard matching.
Table 4.
CPU execution times in milliseconds on the Solaris operating system for checking subclasses of java.security.Permission (FilePermission, PrivateCredentialPermission, ServicePermission, SocketPermission) including the time used for running a control loop
Table 5.
CPU execution times in milliseconds on the Solaris operating system for access to Java-mediated resources (the policy object, resetting of stdout, access to properties) including the time used for running a control loop
Table 6.
CPU execution times in milliseconds on the Solaris operating system for access to operating system resources (files and sockets) including the time used for running a control loop
Abstract
Purchase PDF (281 K)
E-mail Article
Add to my Quick Links
Cited By in Scopus (1)
Purchase PDF (631 K)
