Security Access Control

Guidelines for Programming Security Access Control in Java SE 21

// Check for permission before performing a sensitive operation
SecurityManager securityManager = System.getSecurityManager();
if (securityManager != null) {
  securityManager.checkPermission(new MyCustomPermission("sensitiveOperation"));
}

// Perform the sensitive operation
// ...

Recommended Guidelines Security Access Control

1. Guideline 1: Understand how permissions are checked Points: The standard security check ensures that each frame in the call stack has the required permission (meaning that every operation has to be as unrestricted as its least restricted member) Calling unprivileged code from a privileged frame will cause an exception.
   1. At a minimum, libraries should be granted permissions as liberal as the application code.
   2. Almost all the code shipped in the JDK and extensions is fully privileged.
2. Guideline 2: Beware of callback methods
   Points: Callback methods are generally invoked from the system with full permissions . Examples include the following :
   1. Static initialization is often done with full privileges.
   2. Application main method
   3. Applet/Midlet/Servlet lifecycle events
   4. Runnable.run
3. Guideline 3 Safely invoke java.security.AccessController.doPrivileged
   AccessController Points: Take care when invoking doPrivileged using caller-provided inputs (tainted inputs):
   1. Ensure that privileged operations do not leak sensitive information
   2. Privileged code sections should be made as small as possible.
4. Guideline 4 Know how to restrict privileges through doPrivileged.
   Important Points: When granting permission to a directory ensure that access does not have unintended consequences, you could be providing access to files or sub directories with insecure permissions, or inadvertently providing additional access outside of the directory (for example symbolic links, loop devices, network mounts/ shares )
   1. Running code from or granting access to shared or common directories (including access by means of symbolic links) should be avoided whenever possible.
5. Guideline 5: Be careful caching results of potentially privileged operations..
   Points: A cached result must never be passed to a context that does not have the relevant permissions to generate it.
6. Guideline 6 Understand how to transfer context.
   Points: An access control context can be stored for later use.
   1. You can use a stored context to invoke callback methods in the context that the callback object was registered.
   2. A particular context may be re stored multiple times and even after the original thread has exited.
7. Guideline 7: Understand how thread construction transfers context. Points: Newly constructed threads are executed with the access control context that was present when the thread object was constructed.
   1. To prevent bypassing this context, do not execute the void run method of untrusted objects with inappropriate privileges.
8. Guideline 8: Safely invoke standard API's that bypass SecurityManager checks depending on the immediate caller’s class loader.
   Points: Callers should ensure that they do not inadvertently invoke Class.getClassLoader on behalf of untrusted code 1. Methods that very behavior according to the immediate caller’s class are said to be caller-sensitive , and should be annotated with the @CallerSensitive annotation.
9. Guideline 9 Safely invoke standard APIs that perform tasks using the immediate caller’s class loader instance.
   Points: There are system methods that vary their behavior according to the immediate caller’s class, for example:

   System.loadLibrary(”/com/foo/MyLib.so”) 
   

   
   uses the immediate caller’s class loader to find and load the specified library. (Loading libraries enables a caller to make native method invocations.)
   Do not invoke this method on behalf of untrusted code, since untrusted code may not have the ability to load the same library using its own Class loader instance. Do not invoke any of these methods using inputs provided by untrusted code, and do not propagate objects that are returned by these methods back to untrusted code.

122
10. Guideline 10: Be aware of standard API's that perform Java language access checks against the immediate caller.
    Points:
    1. (primarily in the java.lang.reflect package)
    2. Do not invoke the above API's on behalf of untrusted code. Specifically, do not invoke the above methods on class, constructor, field or method instances that are received from untrusted code. If the respective instances were acquired safely, do not invoke the above methods using inputs that are provided by untrusted code. Also, do not propagate objects that are returned by the above methods back to untrusted code.
11. Guideline 11 Be aware java.lang.reflect.Method.invoke is ignored for checking the immediate caller. Points: 1. Avoid Method.invoke
12. Guideline 12: Avoid using caller-sensitive method names in in interface classes Points:
    1. when designing an interface class, one should avoid using methods with the same name and signature of caller-sensitive methods.
    2. In particular, avoid calling these from default methods on an interface class.
13. Guideline 13: Avoid returning the results of privileged operations.
    Points:
    1. 1. Care should be taken when designing lambdas which are to be returned to untrusted code; especially ones that include security related operations. Without proper precautions, for example, input and output validation, untrusted code may be able to leverage the privileges of a Lambda inappropriately.
    2. 2. Similarly, care should be taken before returning. 1) Method objects, 2) MethodHandle objects, 3) MethodHandles.Lookup objects, 4) VarHandle objects, and 5) StackWalker objects.
14. Guideline 14: Safely invokes standard API's that perform tasks using the immediate caller's module. Points:
    1. For example, Module::addExports uses the immediate caller’s Module to decide if a package should be exported. Do not invoke these methods on behalf of untrusted code, since untrusted code may not have the ability to make the same change.
    2. Do not invoke any of these methods using inputs provided by untrusted code, and do not propagate objects that are returned by these methods back to untrusted code.
15. Guideline 15: Design and use InvocationHandlers conservatively.
    Points: When creating a java.lang.reflect.Proxy instance, a class that implements java.lang.reflect.InvocationHandler is required to handle the delegation of the methods on the proxy instance. The invocation handler is assumed to have the permissions of the code that created the proxy. Thus, access to invocation handlers should not be generally available. 2. Invocation handlers should also validate the method names they are asked to invoke to prevent the invocation handler from being used for a purpose for which it was not intended.
16. Guideline 16:
    Plan module configuration carefully.
    Points When planning a modules configuration, used strong in capsulation to limit the exported packages (both qualified and unqualified exports). Examine all exported packages in classes to be sure that nothing security sensitive has been exposed. Exporting additional packages in the future is easy, but rescinding an export could cause compatibility issues.