Trail: Security Features in Java SE
In this trail you’ll learn how the built-in Java™ security features protect you from malevolent programs. You’ll see how to use tools to control access to resources, to generate and to check digital signatures, and to create and to manage keys needed for signature generation and checking. You’ll also see how to incorporate cryptography services, such as digital signature generation and checking, into your programs.
The security features provided by the Java Development Kit (JDK™) are intended for a variety of audiences:
- Users running programs: Built-in security functionality protects you from malevolent programs (including viruses), maintains the privacy of your files and information about you, and authenticates the identity of each code provider. You can subject applications and applets to security controls when you need to.
- Developers: You can use API methods to incorporate security functionality into your programs, including cryptography services and security checks. The API framework enables you to define and integrate your own permissions (controlling access to specific resources), cryptography service implementations, security manager implementations, and policy implementations. In addition, classes are provided for management of your public/private key pairs and public key certificates from people you trust.
- Systems administrators, developers, and users: JDK tools manage your keystore (database of keys and certificates); generate digital signatures for JAR files, and verify the authenticity of such signatures and the integrity of the signed contents; and create and modify the policy files that define your installation’s security policy.
Note: For developers that want to create applets and Java Web Start applications, see Java Applets for security information.
Trail Lessons
Creating a Policy File shows how resource accesses can be controlled by a policy file. For latest information on policy configuration files, see Policy Guide page.
Quick Tour of Controlling Applications builds on the previous lesson, showing how resource accesses, such as reading or writing a file, are not permitted for applications that are run under a security manager unless explicitly allowed by a permission in a policy file.
API and Tools Use for Secure Code and File Exchanges defines digital signatures, certificates, and keystores and discusses why they are needed. It also reviews information applicable to the next three lessons regarding the steps commonly needed for using the tools or the API to generate signatures, export/import certificates, and so on.
Signing Code and Granting It Permissions illustrates the use of all the security-related tools. It shows the steps that a developer would take to sign and to distribute code for others to run. The lesson also shows how someone who will run the code (or a system administrator) could add an entry in a policy file to grant the code permission for the resource accesses it needs.
Exchanging Files shows use of the tools by one person to sign an important document, such as a contract, and to export the public key certificate for the public key corresponding to the private key used to sign the contract. Then the lesson shows how another person, who receives the contract, the signature, and the public key certificate, can import the certificate and verify the signature.
Generating and Verifying Signatures walks you step by step through an example of writing a Java program using the JDK Security API to generate keys, to generate a digital signature for data using the private key, and to export the public key and the signature to files. Then the example shows writing a second program, which may be expected to run on a different person’s computer, that imports the public key and verifies the authenticity of the signature. Finally, the example discusses potential weaknesses of the approach used by the basic programs and demonstrates possible alternative approaches and methods of supplying and importing keys, including in certificates.
Implementing Your Own Permission demonstrates how to write a class that defines its own special permission.
For More Information
JDK security release documentation can be found at the Security guides page. This index page lists Specifications which present detailed information about latest security features, including architecture specifications, usage guides, API documentation, and tool documentation.
The Security Manager
A security manager is an object that defines a security policy for an application. This policy specifies actions that are unsafe or sensitive. Any actions not allowed by the security policy cause a SecurityException to be thrown. An application can also query its security manager to discover which actions are allowed.
Typically, a web applet runs with a security manager provided by the browser or Java Web Start plugin. Other kinds of applications normally run without a security manager, unless the application itself defines one. If no security manager is present, the application has no security policy and acts without restrictions.
This section explains how an application interacts with an existing security manager. For more detailed information, including information on how to design a security manager, refer to the Security Guide.
Interacting with the Security Manager
The security manager is an object of type SecurityManager ; to obtain a reference to this object, invoke System.getSecurityManager .
SecurityManager appsm = System.getSecurityManager();
If there is no security manager, this method returns null .
Once an application has a reference to the security manager object, it can request permission to do specific things. Many classes in the standard libraries do this. For example, System.exit , which terminates the Java virtual machine with an exit status, invokes SecurityManager.checkExit to ensure that the current thread has permission to shut down the application.
The SecurityManager class defines many other methods used to verify other kinds of operations. For example, SecurityManager.checkAccess verifies thread accesses, and SecurityManager.checkPropertyAccess verifies access to the specified property. Each operation or group of operations has its own checkXXX() method.
In addition, the set of checkXXX() methods represents the set of operations that are already subject to the protection of the security manager. Typically, an application does not have to directly invoke any checkXXX() methods.
Recognizing a Security Violation
Many actions that are routine without a security manager can throw a SecurityException when run with a security manager. This is true even when invoking a method that isn’t documented as throwing SecurityException . For example, consider the following code used to write to a file:
reader = new FileWriter("xanadu.txt"); In the absence of a security manager, this statement executes without error, provided xanadu.txt exists and is writeable. But suppose this statement is inserted in a web applet, which typically runs under a security manager that does not allow file output. The following error messages might result:
appletviewer fileApplet.html Exception in thread "AWT-EventQueue-1" java.security.AccessControlException: access denied (java.io.FilePermission xanadu.txt write) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323) at java.security.AccessController.checkPermission(AccessController.java:546) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.lang.SecurityManager.checkWrite(SecurityManager.java:962) at java.io.FileOutputStream.(FileOutputStream.java:169) at java.io.FileOutputStream.(FileOutputStream.java:70) at java.io.FileWriter.(FileWriter.java:46) .
Note that the specific exception thrown in this case, java.security.AccessControlException , is a subclass of SecurityException .