Java Application Security - Overview

Application security is not easy - we know that. But we also know there are steps we can take to mitigate the risk of security failures. If we are network engineers, we invest in knowledge of network partitioning and packet filters. If we program in C, we protect against buffer overflow. If we program in Java, we consider running our application under the protection of a security manager. In each case, we use knowledge of best practices to give ourselves an advantage over inadvertent system failure.
The security provisions for Java applications are well-documented, and form a superset of the discussion in this article. Our discussion focuses on aspects of Java security managers, a topic which is a small subset of the Java security architecture.
A security manager is a class that is or extends java.lang.SecurityManager, and which checks certain application actions for permissibility during runtime. Once under the control of a security manager, the application can only perform actions that are specifically allowed by an associated security policy. By default that policy is specified in a plaintext policy file. The actions in question include writing files to specific directories, writing system properties, and making network connections to specific hosts, to name only a few. It takes no more than a simple JVM command line option to force a Java application to run under a security manager, and the policy file is easily created with any text editor.
While editing such a security policy file and adding the various rules of interest is not difficult, getting the policy right can be more challenging. And although no one can get that policy right for us, we can use tools to help us understand what that policy should be. Developing and using such a tool is what we are about to undertake. And once we have the broad, fine-grained policy it discovers, we can use it as a starting point in developing a production runtime policy or simply study it to better understand and appreciate our application's security needs.
The core code of this article is a custom security manager whose use requires Sun's JSE 5 JVM. The JSE 5 requirement derives from the security manager's dependence on the Java Reflection API to acquire private member data from a particular Java system class. Use of the Reflection API is required because of a lack of public access to certain private member data which the manager needs to function. The consequence of using reflection of private members is that the manager becomes strongly bound to the JVM internals on which it runs. This is not a serious consequence, however, as the manager is a development tool, not a production component. Once the manager has suggested a policy starting point, we can take that policy and run our application subject to it on any modern JVM.
The Default Java Security Manager
The vast majority of Java code we see written, discussed, and invoked in the contemporary literature represents the application that does not run subject to a security manager. Such applications therefore have full access to all machine resources, including disk, network, and application shutdown. Such broad access is easily restricted, however. An application can be forced to run under the default Java security manager simply by setting the -Djava.security.manager option on the JVM command line.For Examples Click Here..