Principle of Least Privilege

Wiki MarkupAccording 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 their 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 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. When a Java program is run with a security manager in place, the default security policy file grants permissions sparingly, however, 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 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 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.

...

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 prevent 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.

...

• Providing backward compatibility: Legacy code often contains custom implementations of the security manager class because it was originally abstract.
• Defining custom policies: Subclassing the security manager permits definition of custom security policies (for example, multilevel, coarse, or fine grain).

...

Regarding the implementation and use of custom security managers, as opposed to default ones, the Java Security Architecture Specification \[java: [SecuritySpec 2008|AA. Bibliography#SecuritySpec 08]\] states

We encourage the use of AccessController in application code, while customization of a security manager (via subclassing) should be the last resort and should be done with extreme care. Moreover, a customized security manager, such as one that always checks the time of the day before invoking standard security checks, could and should utilize the algorithm provided by AccessController whenever appropriate.

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

...

Loader

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. ClassLoader itself is abstract, so it cannot be instantiated. All class loaders inherit from SecureClassLoader, which itself inherits from ClassLoader. SecureClassLoader performs security checks on its members, as do its descendents. It defines a getPermissions() method, which indicates the privileges available to classes loaded by the class loader, This serves to provide protection mechanisms limiting what additional classes may be loaded by untrusted code.

Misc.

This is more classloader stuff that isn't strictly necessary to understand the rules

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.unmigrated-wiki-markup

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:

...

When any method from the following table is invoked on a Class, ClassLoader or Thread object, a comparison is run between the method's immediate caller's class loader and that of the object on which the method is invoked. (SCG 2007)

Wiki MarkupAs an example of what constitutes the immediate caller and the object, consider the method {{java.lang.Class.newInstance()}}. Here, the immediate caller is the class that contains this method call whereas the object on which the {{newInstance()}} method is being invoked is referred to as the {{Class}} object ({{classObjectName.newInstance()}}). According to the Java Language Specification \[ [JLS 2005|AA. Bibliography#JLS 05]\], the method {{getClass()}} returns the {{Class}} object that represents the class of the object.

If a security manager is present, untrusted code that does not have the permissions to use the API directly is prevented from indirectly using trusted code containing the API call to perform the operation. However, the security manager checks are bypassed if the class loader of the immediate caller is the same as or the delegation ancestor of the class loader of the object on which the API is invoked. Consequently, untrusted callers who do not have the required permissions but are capable of passing the class loader check are able to perform sensitive operations if the trusted code invokes these APIs on their behalf.

...