...

According to the principle of least privilege, every program and every user of the system should operate using the least set of privileges necessary to complete thetheir particular task \[[Saltzer 1974|AA. Bibliography#Saltzer 74], [Saltzer 1975|AA. Bibliography#Saltzer 75]\]. The Build Security In website \[[DHS 2006|AA. Bibliography#DHS 06]\] provides additional definitions of this principle. Executing with minimal privileges mitigates against exploitation in case a vulnerability is discovered in the code.  These principles can be applied in various ways to Java language programming. Occasionally a system will have components, most of which require only a base set of privileges, but a few require more privileges than the base set; these are said to run with elevated privileges.

Only Java code should be run with the minimum required privileges. Sign only the code that requires elevated privileges should be signed; other code should not be signed. (See rule ENV00-J. Do not sign code that performs only unprivileged operations.) The security policy that defines the set of permissions should be as restrictive as possible. The When a Java program is run with a security manager in place, the default security policy file grants permissions sparingly, however, the Java's flexible security model allows the user to grant additional permissions to applications by defining a custom security policy. Specific rules that enforce this principle include:

...

Code that needs to be signed can coexist with unsigned classes in the same package (or JAR file). It is recommended that all privileged code be packaged together. (See rule ENV01-J. Place all security-sensitive code in a single jar and sign and seal it for more information.) Furthermore, it is possible to grant privileges to code on the basis of the code base and/or its signer using a security policy.

Privileged operations should be limited to the smallest possible code blocks that require such privileges. The Java AccessController mechanism allows only certain parts of code to acquire elevated privileges. When a class needs to assert its privileges, it executes the privileged code in a doPrivileged() block. The AccessController mechanism works in conjunction with the security policy in effect. Because users may be unaware of the details of the security model and incapable of correctly configuring security policies tailored to their requirements, privileged code present within the doPrivileged() blocks must be kept to a minimum to avoid security vulnerabilities.

Security Manager

A security manager is an object SecurityManager is a Java class that defines a security policy for Java code. This policy specifies actions that are unsafe or sensitive. Any actions not allowed by the security policy cause a SecurityException to be thrown. Code can also query its security manager to discover which actions are allowed. The security manager can also be used to control the functions the trusted Java API can perform. When untrusted code should be disallowed from accessing system classes, it should be granted specific permissions to prevent it from accessing trusted classes in the specified packages. The accessClassInPackage permission provides the required functionality.

Certain sensitive classes, such as java.lang.ClassLoader, have the ability to modify or completely avoid security manager access controls. Many class loaders check package access permissions before attempting to load a class (see table below). However, instantiating a URLClassLoader using either of its constructors bypasses the call to the security manager's checkPackageAccess() method. Although the package access check is an optional step (no Oracle-manufactured URL class loader performs it), it is a good idea to ensure that the program is actually allowed to access the class being loaded.

According to the Java API \[java:[API 2006|AA. Bibliography#API 06]\] the {{ClassLoader.checkPackageAccess()}} method documentation:

Throws a SecurityException if the calling thread is not allowed to access the package specified by the argument. This method is used by the loadClass method of class loaders. This method first gets a list of restricted packages by obtaining a comma-separated list from a call to java.security.Security.getProperty("package.access") and checks to see if pkg starts with or equals any of the restricted packages. If it does, then checkPermission gets called with the RuntimePermission("accessClassInPackage."+pkg) permission.

In 2004, Schoenefeld \[java:[Schoenefeld 2004|AA. Bibliography#Schoenefeld 04]\] discovered a vulnerability in Opera v7.54 in that the default security policy granted the runtime permission {{"accessClassInPackage.sun.*"}} to unprivileged applets so that they could access internal Sun packages. This allowed attackers to obtain sensitive local information and crash the client web browser. 

The following table shows which class loaders check package access permissions and which do not:

* A URLClassLoader, when constructed using the default constructor, does not check package access permissions. However, when the static newInstance() method is used, the obtained instance carries out the check.

Doing so does not limit what system classes can do; however, it restricts the range of system packages that can be used from less-privileged code.

According to the Java API \[java:[API 2006|AA. Bibliography#API 06]\], class {{SecurityManager}} documentation

The security manager is a class that allows applications to implement a security policy. It allows an application to determine, before performing a possibly unsafe or sensitive operation, what the operation is and whether it is being attempted in a security context that allows the operation to be performed. The application can allow or disallow the operation.

The applet security manager There are several predefined security managers available for certain types of applications. The applet security manager is used to manage all Java applets. It denies applets all but the most essential privileges. It is designed to protect inadvertent system modification, information leakage and user impersonation. The use of security managers is not limited to client side protection. Webservers, such as Tomcat and Websphere, use this facility to isolate trojan servlets and malicious JSP code, as well as to protect sensitive system resources from inadvertent access.

For Java applications that run from the command line, a default or custom security manager can be set using a special flag. Alternatively, it is possible to install a security manager programmatically. Installing a security manager this way programmatically helps create a default sandbox that allows or denies sensitive actions based on the security policy in effect.

From Java 2 SE Platform onwards, the SecurityManager class is a non-abstract class. As a result, there is no explicit requirement of overriding its methods. To create and use a security manager programmatically, the code must have the runtime permissions createSecurityManager (to instantiate SecurityManager) and setSecurityManager to install it. These permissions are checked only if a security manager is already installed. This is useful for situations where there is a global-default security manager in place, such as on a virtual host, and individual hosts need to be denied the requisite permissions for overriding the default security manager with a custom one.

...

Many of the Java SE APIs perform security manager checks by default before performing sensitive operations. For example, the constructor of class java.io.FileInputStream throws a SecurityException if the caller does not have the permission to read a file. Because SecurityException is a subclass of RuntimeException, the declarations of some API methods (for example, those of the java.io.FileReader class) may lack a throws clause that lists the SecurityException. Avoid depending on the presence or absence of security manager checks that are not specified in the API method's documentation.

Class Loading Security

The java.lang.ClassLoader class and its descendent classes are the means by which new code is dynamically loaded into the JVM. Every class provides a link to the ClassLoader that loaded it; furthermore every class loader class also has its own class that loaded it, on down to a single 'root' class loader.

Class loaders, as well as some other sensitive classes, have the ability to modify or completely avoid security manager access controls. Many class loaders check package access permissions before attempting to load a class (see table below). However, instantiating a URLClassLoader using either of its constructors bypasses the call to the security manager's checkPackageAccess() method. Although the package access check is an optional step (no Oracle-manufactured URL class loader performs it), it is a good idea to ensure that the program is actually allowed to access the class being loaded.

According to the Java API \[java:[API 2006|AA. Bibliography#API 06]\] the {{ClassLoader.checkPackageAccess()}} method documentation:

Throws a SecurityException if the calling thread is not allowed to access the package specified by the argument. This method is used by the loadClass method of class loaders. This method first gets a list of restricted packages by obtaining a comma-separated list from a call to java.security.Security.getProperty("package.access") and checks to see if pkg starts with or equals any of the restricted packages. If it does, then checkPermission gets called with the RuntimePermission("accessClassInPackage."+pkg) permission.

In 2004, Schoenefeld \[java:[Schoenefeld 2004|AA. Bibliography#Schoenefeld 04]\] discovered a vulnerability in Opera v7.54 in that the default security policy granted the runtime permission {{"accessClassInPackage.sun.*"}} to unprivileged applets so that they could access internal Sun packages. This allowed attackers to obtain sensitive local information and crash the client web browser. 

The following table shows which class loaders check package access permissions and which do not:

* A URLClassLoader, when constructed using the default constructor, does not check package access permissions. However, when the static newInstance() method is used, the obtained instance carries out the check. Doing so does not limit what system classes can do; however, it restricts the range of system packages that can be used from less-privileged code.

The following text comes from SCG 2007, it is instructional and maybe useful in an introduction.

...