Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8338625

JEP 486: Permanently Disable the Security Manager

XMLWordPrintable

    • Sean Mullan & Alex Buckley
    • Feature
    • Open
    • SE
    • security dash dev at openjdk dot java dot net
    • L
    • L
    • 486

      Summary

      The Security Manager has not been the primary means of securing client-side Java code for many years, it has rarely been used to secure server-side code, and it is costly to maintain. We therefore deprecated it for removal in Java 17 via JEP 411 (2021). As the next step toward removing the Security Manager, we will revise the Java Platform specification so that developers cannot enable it and other Platform classes do not refer to it. This change will have no impact on the vast majority of applications, libraries, and tools. We will remove the Security Manager API in a future release.

      Goals

      • Remove the ability to enable the Security Manager when starting the Java runtime (java -Djava.security.manager ...).

      • Remove the ability to install a Security Manager while an application is running (System.setSecurityManager(...)).

      • Improve the maintainability of hundreds of JDK classes that currently delegate resource-access decisions to the Security Manager.

      • Revise the specification of the Security Manager API so that all implementations of it behave as if no Security Manager is ever enabled.

      • Retain the Security Manager API in this release, so that maintainers of existing code that depends upon it have time to migrate away.

      Non-Goals

      • It is not a goal to provide a replacement for any of the Security Manager's functionality, in particular the ability to sandbox Java code or intercept calls to the Java Platform API.

      Motivation

      The Security Manager has been a feature of the Java Platform since its first release. It is based upon the principle of least privilege: Code is untrusted by default, so it cannot access resources such as the filesystem or the network, and developers place trust in specific code by granting it permission to access specific resources. In theory, this can protect machines and applications against code that contains accidental vulnerabilities or was crafted with malicious intent. In practice, however, the permission scheme is so complex that the Security Manager has always been disabled by default, and its use is exceedingly rare.

      Despite the fact that the Security Manager is disabled by default, the least-privilege model induces extraordinary complexity in the Java Platform libraries. From networking, I/O, and JDBC, to XML, AWT, and Swing, the libraries must implement the least-privilege model in case the Security Manager is enabled:

      The OpenJDK Core Libraries Group devotes significant time and energy to reviewing every change to any of these methods. Every new API must be designed, and its implementation carefully audited, with the least-privilege model in mind. However, only a tiny number of applications actually enable the Security Manager. To make matters worse, most of them, in our experience, blindly grant all permissions to their code, thereby giving up the benefits of the least-privilege model.

      We therefore deprecated the Security Manager, for removal, in Java 17 via JEP 411 (2021). In addition to terminally deprecating the Security Manager API and related APIs, we also revised the JDK to issue warning messages when the Security Manager is enabled. These changes were designed to prepare users and developers for the removal of the Security Manager in a future release.

      Deprecating the Security Manager had hardly any impact

      JDK 17 and later releases enjoyed wide adoption as developers and enterprises upgraded from JDK 8 and JDK 11. We have seen hardly any discussion in the Java ecosystem about the warnings that these releases issue when enabling the Security Manager. This indicates that the Security Manager is almost completely irrelevant to current Java developers. We appear to have been correct when we said, in JEP 411, that,

      "In the quarter-century since the Security Manager was introduced, adoption has been low”,

      and,

      "In summary, there is no significant interest in developing modern Java applications with the Security Manager."

      Since the release of JDK 17, the maintainers of some of the handful of frameworks and tools that supported the Security Manager have removed support for it; these include Derby, Ant, SpotBugs, and Tomcat. The maintainers of Jakarta EE removed the requirement for EE applications to support the Security Manager. We are not aware of any new projects that support the Security Manager.

      Moving forward

      The vast majority of applications, libraries, and tools do not require the Security Manager, do not recommend the Security Manager, do not use the Security Manager, and do not work if other code uses the Security Manager. It is time for the Java ecosystem to take the next step and stop using the Security Manager entirely.

      We will therefore revise the specification of the Security Manager so that developers cannot enable it, and we will revise the specifications of other Java Platform libraries so that they do not delegate resource-access decisions to it. We will leave a minimal version of the java.lang.SecurityManager class in place for compatibility with the few applications, libraries, and tools that still use it. We will remove this class in a future release.

      Removing the Security Manager will improve Java security

      We believe that the vast majority of Java developers would prefer to see the OpenJDK Core Libraries Group focus on practical security features needed by Internet-facing applications. The above revisions to the specification will allow us to remove the implementation of the Security Manager from the JDK codebase, together with thousands of permission checks and privilege elevations. That, in turn, will make more contributor time and energy available for other work such as

      Most contemporary security threats involve malicious data, against which the Security Manager is ill equipped to defend. Removing the implementation of the Security Manager will make more contributor time and energy available for security features that defend against malicious data directly, such as:

      • Safer serialization — The process of deserialization involves interpreting a stream of data that might have been crafted with malicious intent. In 2017, Java 9 introduced deserialization filters so that developers can prevent malicious data from being deserialized in the first place. For the longer term, work is already underway toward a better approach to serialization.

      • Stricter XML processing — XML documents can refer to Document Type Definitions (DTDs) anywhere on the Internet, causing the JDK to open network connections to untrusted machines. In JDK 23, application developers can lock down XML processing by starting the Java runtime with java -Djava.xml.config.file=... and specifying a configuration file that prohibits outbound connections.

      Sandboxing Java code

      Sandboxing is the ability to run some Java code with different permissions than other code. The permissions for each piece of code are determined by a security policy, which is enforced by the Security Manager. Code running with restricted permissions, such as untrusted or potentially hostile code, is often referred to as being in a sandbox.

      Historically, the Security Manager was used to sandbox applets; we never recommended it for sandboxing entire applications. Java applications should be sandboxed in the same way as native applications, using technologies outside the JDK such as containers, hypervisors, and OS mechanisms such as the macOS App Sandbox or the Linux seccomp feature. Like the Security Manager, these technologies can restrict how applications use local and remote resources; they can, e.g., prevent code from accessing the network to exfiltrate data. Unlike the Security Manager, however, they have wide adoption and are relatively easy to learn and use effectively.

      Intercepting calls to the Java Platform API

      A small number of applications have used the Security Manager not to enforce a security policy but, rather, as a means to intercept calls to the Java Platform API. In the absence of a security policy and permission checking, calls to the Java Platform API are no longer a security concern as such. Truly malicious code has innumerable ways to bypass the Security Manager's interception of API calls. Nonetheless, some applications find interception useful, particularly to block calls to methods such as System::exit.

      We designed, prototyped, and evaluated a variety of mechanisms that an application could use instead of the Security Manager to intercept calls to the Java Platform API. We found that the use cases were too broad, and the requirements too diffuse, to support the introduction of such a mechanism. The OpenJDK Core Libraries Group is unwilling to maintain an arbitrary number of API interception points with ill-defined requirements across the JDK in perpetuity.

      In most cases, we found that issues that seemed to need interception could be adequately addressed outside the JDK, using techniques such as source code modification, static code analysis and rewriting, or agent-based dynamic code rewriting at class load time. See the Appendix for an example of an agent that uses dynamic code rewriting to intercept calls to System::exit.

      The Security Manager in older Java releases

      The Security Manager will continue to be available in every release prior to JDK 24. Application deployers who are wary of adopting new releases because they value stability above all else are unlikely ever to upgrade to JDK 24, and therefore will never be affected by changes to the Security Manager in JDK 24 or subsequent releases.

      Description

      In JDK 24, we will:

      • Remove the ability to enable the Security Manager at startup,
      • Remove the ability to install a custom Security Manager during run time, and
      • Render the Security Manager API non-functional, in advance of removing the API in a future release.

      Enabling the Security Manager in JDK 24 is an error

      In JDK 24, you cannot enable the Security Manager at startup, nor can you install a custom Security Manager during run time.

      • It is an error to enable a Security Manager at startup, for example via:

        $ java -Djava.security.manager                  -jar app.jar
$ java -Djava.security.manager=""               -jar app.jar
$ java -Djava.security.manager=allow            -jar app.jar
$ java -Djava.security.manager=default          -jar app.jar
$ java -Djava.security.manager=com.foo.CustomSM -jar app.jar

        Attempting to do so causes the JVM to report the error and then exit:

        Error occurred during initialization of VM
java.lang.Error: A command line option has attempted to allow or enable the Security Manager. Enabling a Security Manager is not supported.
      at java.lang.System.initPhase3(java.base@24/System.java:2067)

        You cannot suppress this error message, nor can you reduce it to the warnings given in JDK 17 through 23.

        (The five invocations of java -D... shown above set the system property java.security.manager to, respectively, the empty string, the empty string, the string allow, the string default, and the class name of a custom Security Manager.)

      • It is not an error to disable the installation of a custom Security Manager during run time, for example via:

        $ java -jar app.jar
$ java -Djava.security.manager=disallow -jar app.jar

        No warning or error message is issued at startup, and the application runs without a Security Manager, just as it did before.

        (The default value of java.security.manager has been <code class="prettyprint" data-shared-secret="1734791522944-0.4355586881451047">disallow</code> since JDK 18, so java -jar app.jar means the same as java -Djava.security.manager=disallow -jar app.jar.)

      • It is an error to install a Security Manager at run time by calling System::setSecurityManager. Attempting to do so causes the JVM to throw an UnsupportedOperationException with the detail message

        Setting a Security Manager is not supported

      How to determine if an application enables the Security Manager

      If you are not sure whether your application enables the Security Manager, here are some things you can do to find out:

      Rendering the Security Manager API non-functional

      The Security Manager API consists of:

      • Methods in the java.lang.SecurityManager class,
      • Methods in the AccessController, AccessControlContext, Policy, and ProtectionDomain classes of the java.security package, and
      • The getSecurityManager and setSecurityManager methods in the java.lang.System class.

      We are not removing these methods from Java 24; rather, we are degrading their behavior. They will, as appropriate, return null or false, or pass through the caller's request, or unconditionally throw a SecurityException. The full set of behavioral changes is available here.

      In addition to changing the behavior of the API, we will:

      Changes elsewhere in the Java Platform API

      Approximately 1,000 constructors and methods in the Platform are specified to throw SecurityException if the Security Manager is enabled and appropriate permissions have not been granted. They span 264 classes, 73 packages, and 25 modules. For example, java.base has 640 methods specified to throw SecurityException.

      In Java 24, we will revise the specifications of all such constructors and methods to remove mentions of SecurityException since that exception will now never be thrown. The complete list of revised constructors and methods is available here.

      Here is an example of the specification change for a constructor in java.io.FileOutputStream (struck through text is deleted):

      public FileOutputStream(String name)
         throws FileNotFoundException

Creates a file output stream to write to the file with the specified
name. A new FileDescriptor object is created to represent this file
connection.

First, if there is a security manager, its checkWrite method is
called with name as its argument.

If the file exists but is a directory rather than a regular file,
does not exist but cannot be created, or cannot be opened for any
other reason then a FileNotFoundException is thrown.

Implementation Requirements:
   Invoking this constructor with the parameter name is equivalent
   to invoking new FileOutputStream(name, false).
Parameters:
   name - the system-dependent file name.
Throws:
   FileNotFoundException - if the file exists but is a directory
   rather than a regular file, does not exist but cannot be created,
   or cannot be opened for any other reason
   SecurityException - if a security manager exists and its checkWrite
   method denies write access to the file.
See Also:
   SecurityManager.checkWrite(java.lang.String)

      Advice to maintainers of libraries that support the Security Manager

      A small number of libraries were designed to use the Security Manager if it is enabled. These libraries typically employ two idioms:

      • Calling System::getSecurityManager to check if a Security Manager is enabled and, if so, calling SecurityManager::checkPermission to check if an operation should be granted or denied:

        SecurityManager sm = System.getSecurityManager();
if (sm != null) {
    sm.checkPermission(...);
}

      • Calling AccessController::doPrivileged to execute code with different permissions from the calling code:

        SomeReturnValue v = AccessController.doPrivileged(() -> {
    ...
    return theResult;
});

      In JDK 24, where a Security Manager is never enabled, the System::getSecurityManager and AccessController::doPrivileged methods behave as they did in JDK 17 when a Security Manager was not enabled:

      • System::getSecurityManager returns null,
      • The SecurityManager::check* methods throw SecurityException, and
      • The six AccessController::doPrivileged methods execute the given action immediately.

      Accordingly, the small number of libraries that call these methods will run on JDK 24 without change. However, we strongly recommend that new releases of these libraries do not call these methods, which we will remove in a future release.

      A very small number of libraries use advanced parts of the Security Manager API to implement a custom execution environment. For example, a library might call AccessController::checkPermission to enforce its own permission model, or call Policy::setPolicy to make custom Security Managers treat certain resources as off-limits. These methods are non-functional in JDK 24 in order to provide an execution environment that disallows access to all resources by default. We will remove them in a future JDK release.

      Future Work

      Removing related APIs

      We are not removing any classes or methods from the Java Platform API in Java 24. In a future release we will remove the Security Manager APIs that we deprecated in Java 17. In future releases we may, further, deprecate and remove additional classes and methods in the java.lang and java.security packages.

      • We are not deprecating SecurityException now because it is used elsewhere in the JDK in situations that are unrelated to the Security Manager, despite the fact that its specification says, "Thrown by the security manager to indicate a security violation". Here are examples of its (mis)use:

        • java.lang.ClassLoader::defineClass throws SecurityException if the name of the class being defined starts with "java.".

        • java.lang.reflect.Constructor::setAccessible throws it if invoked on the Constructor object for a constructor of java.lang.Class.

        • java.util.java.JarInputStream throws it when signed JAR entries are signed incorrectly.

        After reexamining these misuses, we may deprecate SecurityException in a future release.

      • In a future release we will deprecate Permission and related classes such as BasicPermission, PermissionCollection, and Permissions, and also subclasses of Permission outside of the java.security package, such as java.lang.RuntimePermission, java.net.NetPermission, and java.lang.reflect.ReflectPermission.

      • In a future release we will deprecate PrivilegedAction, PrivilegedExceptionAction, and PrivilegedActionException. We did not deprecate these classes in Java 17 because they appear in method signatures of javax.security.auth.Subject, a class unrelated to the Security Manager. In Java 18, we added replacement methods to javax.security.auth.Subject that do not use the Privileged* classes. We will eventually remove both the old methods and the Privileged* classes.

      Removing or revising related features

      Various early Java Platform features were designed around a vision of mobile objects. They used serialization to move code and data between JVMs, and assumed applications would enable the Security Manager to defend against maliciously serialized objects. This vision did not gain any traction. Given the fundamental flaws in serialization and the minimal use of the Security Manager, we have either already removed these features or else we plan to do so:

      • JMX Management Applets ("m-lets") were introduced in Java 5 and allowed remote MBeans to be dynamically loaded and executed with the Security Manager enabled. M-lets saw essentially no use. We deprecated the m-let API for removal in Java 20 and removed it in Java 23.

      • JNDI has support for reconstructing objects that were serialized to an LDAP database (RFC 2713). This feature of JNDI has been disabled by default since Java 6 but can be enabled via system properties. Using this feature securely relies on enabling the Security Manager, so it will not be possible to use the feature securely once the Security Manager is removed. Accordingly, we will remove this feature, along with the remote class loading feature of the JNDI RMI Registry service provider, in a future release.

      • RMI supports dynamic code loading, but it is enabled only when the Security Manager is enabled. This feature of RMI has been disabled by default since 2013. With the removal of the Security Manager, it is no longer possible to use this feature. We may remove it in a future release.

      Separately, the javax.xml APIs allow Java source code to be embedded directly in XSLT and XPath documents as extension functions. This feature is enabled by default but, historically, it was disabled when running with the Security Manager. We will disable this feature by default in a future release, as part of a broader effort toward stricter XML processing.

      Testing

      The breadth of the Security Manager API and the depth of its support in the JDK codebase is reflected in the approximately 4,000 tests developed for it since JDK 1.0. They fall into three categories:

      • Tests that directly exercise functionality of the Security Manager, e.g., making sure that permissions are enforced correctly.

      • Tests that address security vulnerabilities, which typically ensure that it is no longer possible for specific exploits that allowed untrusted code, such as applets, to escape the sandbox.

      • Conformance tests which ensure that the Security Manager implementation complies with the specification of the Security Manager API.

      Permanently disabling the Security Manager will make these tests irrelevant since the functionality will no longer be supported and the concept of a sandbox will no longer exist. Including tests, we will delete over 50,000 lines of code.

      Alternatives

      The numerous check* methods in the Security Manager API always throw an exception so as to avoid unconditionally permitting operations that formerly required a permission check, and thus might not have been permitted. This may be inconvenient for application maintainers, who may have to take some corrective action. An alternative would be to have these methods always succeed, but that would allow an application to operate insecurely without notifying the maintainer.

      Risks and Assumptions

      Appendix

      An agent is a Java program that can alter the code of an application while the application is running. Agents achieve this by transforming the bytecodes of methods when classes are loaded, or by redefining classes after they have been loaded.

      Here is an agent that blocks code from calling System::exit. The agent declares a premain method that is run by the JVM before the main method of the application. This method registers a transformer that transforms class files as they are loaded from the class path or module path. The transformer rewrites every call to System.exit(int) into throw new RuntimeException("System.exit not allowed").

      The transformer reads and writes bytecodes in class files using the Class-File API, which is a preview feature in JDK 23. See the <code class="prettyprint" data-shared-secret="1734791522944-0.4355586881451047">java.lang.classfile</code> package for details. The agent's source code imports the Class-File API and other Java APIs with module import declarations, which are also a preview feature in JDK 23.

      import module java.base;
import module java.instrument;

public class BlockSystemExitAgent {
    /*
     * Before the application starts, register a transformer of class files.
     */
    public static void premain(String agentArgs, Instrumentation inst) {
        var transformer = new ClassFileTransformer() {
            @Override
            public byte[] transform(ClassLoader      loader,
                                    String           className,
                                    Class<?>         classBeingRedefined,
                                    ProtectionDomain protectionDomain,
                                    byte[]           classBytes) {
                if (loader != null && loader != ClassLoader.getPlatformClassLoader()) {
                    return blockSystemExit(classBytes);
                } else {
                    return null;
                }
            }
        };
        inst.addTransformer(transformer, true);
    }

    /*
     * Rewrite every invokestatic of System::exit(int) to an athrow of RuntimeException.
     */
    private static byte[] blockSystemExit(byte[] classBytes) {
        var modified = new AtomicBoolean();
        ClassFile cf = ClassFile.of(ClassFile.DebugElementsOption.DROP_DEBUG);
        ClassModel classModel = cf.parse(classBytes);

        Predicate<MethodModel> invokesSystemExit =
            methodModel -> methodModel.code()
                                      .map(codeModel ->
                                             codeModel.elementStream()
                                                      .anyMatch(BlockSystemExitAgent::isInvocationOfSystemExit))
                                      .orElse(false);

        CodeTransform rewriteSystemExit =
            (codeBuilder, codeElement) -> {
                if (isInvocationOfSystemExit(codeElement)) {
                    var runtimeException = ClassDesc.of("java.lang.RuntimeException");
                    codeBuilder.new_(runtimeException)                    
                               .dup()
                               .ldc("System.exit not allowed")
                               .invokespecial(runtimeException,
                                   "<init>",
                                   MethodTypeDesc.ofDescriptor("(Ljava/lang/String;)V"),
                                   false)
                               .athrow();
                    modified.set(true);
                } else {
                    codeBuilder.with(codeElement);
                }
            };

        ClassTransform ct = ClassTransform.transformingMethodBodies(invokesSystemExit, rewriteSystemExit);
        byte[] newClassBytes = cf.transform(classModel, ct);
        if (modified.get()) {
            return newClassBytes;
        } else {
            return null;
        }
    }

    private static boolean isInvocationOfSystemExit(CodeElement codeElement) {
        return codeElement instanceof InvokeInstruction i
                && i.opcode() == Opcode.INVOKESTATIC
                && "java/lang/System".equals(i.owner().asInternalName())
                && "exit".equals(i.name().stringValue())
                && "(I)V".equals(i.type().stringValue());
    }
}

      You must package the agent in a JAR file and specify it via the -javaagent option when starting the application:

      # Compile the agent into the agentclasses directory, enabling preview features for JDK 23
$ javac --enable-preview --release 23 -d agentclasses BlockSystemExitAgent.java

# Create JAR file manifest in agent.mf
$ cat > agent.mf << EOF
Premain-Class: BlockSystemExitAgent
Can-Retransform-Classes: true
EOF

# Create the agent JAR (Note there is a period after -C agentclasses)
$ jar --create --file=BlockSystemExitAgent.jar --manifest=agent.mf -C agentclasses .

# Run application with the agent JAR, enabling preview features for JDK 23
$ java --enable-preview -javaagent:BlockSystemExitAgent.jar -jar app.jar

            mullan Sean Mullan
            abuckley Alex Buckley
            Sean Mullan Sean Mullan
            Alan Bateman, Mark Reinhold, Stuart Marks
            Alan Bateman
            Votes:
            1 Vote for this issue
            Watchers:
            17 Start watching this issue

              Created:
              Updated: