Jun 01, 2021 4 min read

Following the introduction of JEP-411 to deprecate Java’s SecurityManager, several projects have spoken up to discuss the impact and expected outcome of this change and how it is implemented in early-release builds of Java 17 (a Long-Term Support release). In particular, Oracle has published a technical paper, "Security and Sandboxing Post SecurityManager," while Apache NetBeans has advocated that they use the SecurityManager and the project fails to start in JDK17-EA.

The Post-Security Manager paper by Loom project lead Ron Pressler provides additional context to justify the deprecation:

• The SecurityManager class was designed to defend against threats posed by untrusted code… Servers tend to mostly run trusted code... and the threats facing it are exploits of vulnerabilities that cause trusted code to perform unintended operations through carefully manipulated inputs.
• Few use the Security Manager.
• The high cost of maintaining it is no longer justified by its benefits.

The paper lays out a set of solutions involving shallow/deep sandboxes that can allow or disallow sensitive operations baed on the context of the calling code. An example is provided to demonstrate the way that this new structure could disallow a specific module in the code, such as an untrusted library, from calling sensitive code like the functions in java.lang.Runtime.

Common Threats Against Java Applications

The types of threats affecting most applications are tracked by several organizations in the security and software development communities: OWASP maintains the OWASP Top 10, SANS manages the SANS Top 25, and Verizon publishes an annual Verizon Data Breach Incident Report (DBIR).

The 2020 DBIR was based on approximately 29,000 breaches and cites an uptick in attack patterns used against web applications. Attack patterns in these scenarios match the definition of "carefully manipulated input" cited by Pressler in the SecurityManager article. The DBIR appendix specifically lists a May incident attack on Oracle Weblogic (CVE-2020-2883) that leveraged a Java deserialization flaw (OWASP A8). Deserialization flaws are a common class of attack against applications where a trusted web-accessible library is attacked with malformed input through gadgets like ysoserial. The Weblogic exploit succeeded even though WebLogic published guidance for using the SecurityManager.

While OpenJDK does offer serialization defenses, they reside in the serialization filter mechanism rather than the SecurityManager.

Usage of the SecurityManager

While API or feature-level usage statistics are not published in the Java community, various standards or recognized publications provide guides for hardening systems. Many guides provide common recommendations but many make no mention of the SecurityManager:

• The DISA STIG (Secure Technology Implementation Guide) for Java 8 provides 16 findings but does not mention the SecurityManager, making its usage optional. STIGs are mandatory for the US Department of Defense.
• The operations guide and security features documentation of a major Java in-memory data grid exceeds 100 pages and does not use, recommend, or refer to the SecurityManager and does provide policy configuration files or indicate needed permissions.
• AppDynamics does provide guidance for the SecurityManager however the sample policy file grants java.security.AllPermission rather than applying the principle of least privilege.
• Datastax’ guide to Securing Cassandra, a Java NoSQL database, does not reference the SecurityManager or provide policy files.
• Payara and Snyk co-published "How to Develop Applications with Minimal Security Risks," a ten-page guide for Java developers that does not mention the SecurityManager. Snyk authored a separate guide of practices that does recommend the SecurityManager, however its co-author contradicts saying, "I have literally never used the SM in enterprise development."
• JBoss, like WebLogic, does provide guidance for using the SecurityManager.

The usage or lack of usage on the SecurityManager does not imply a security deficiency in any product or company.

Apache NetBeans, Solr, River, ElasticSearch, and Eclipse are affected

Several projects have spoken up during the JEP process to voice concern about the deprecation and way in which it is handled. Apache NetBeans published a blog concerned that the application does not even start in JDK 17-EA. This follows a previous blog where the integrated development environment discussed their usage of the SecurityManager not as a compensating control but as a way to detect API usage of plugins that operate within the IDE. NetBeans is impacted as a result of a newly-changed system property from Java 12 that must be enabled as a feature flag from the command line. The change of this feature flag is atypical with previous deprecation notices, coming at the same time as the deprecation annotation and before it is even marked with the forRemoval boolean type.

One aspect of the contention is that a 30 days review period was too short to change behavior of an approximately 20 year old feature.

Eclipse discussed their own impact with the feature flag in a ticket regarding the expected change.

OpenJDK maintainers have since shifted the property back to its original value, providing more reaction time for downstream projects to adjust in the lifetime of JDK 17 being an LTS release.

Peter Firmstone from the Apache River project posted a piece on Foojay about, "The Principle of Least Privilege and How JEP 411 Will Have a Negative Impact on Java Security." The post lays out the SecurityManager’s benefits to users of Apache River. The post also acknowledges that many developers outside the project do not use the SecurityManager, however it provides a utility that simplifies the creation of policy files.

Next Steps in the JEP Process

The resulting work on JEP-411 remains several months away as parties work together to share maintenance and help across the community. Future steps involve the migration of JEP (Java Enhancement Proposal) to JSR (Java Spec Review), which ultimately receives a vote from the Java Community Process Executive Committee.

How might we improve InfoQ for you

Thank you for being an InfoQ reader.

Each year, we seek feedback from our readers to help us improve InfoQ. Would you mind spending 2 minutes to share your feedback in our short survey? Your feedback will directly help us continually evolve how we support you.

Take the Survey