BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News OpenJDK Discusses Post-SecurityManager Practices

OpenJDK Discusses Post-SecurityManager Practices

This item in japanese

Bookmarks

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, the Java team inside Oracle has published a view on the future, "Security and Sandboxing Post SecurityManager," while Apache NetBeans has advocated that they use the SecurityManager and the project would have failed to start in JDK17-EA if a property were altered as originally proposed.

The decision to alter the property has since been postponed to JDK 18 (a non-LTS release) to provide time for affected projects to adjust. The Post-Security Manager article 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 based 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 in most Java applications and workloads. STIGs are mandatory for the US Department of Defense.
    The STIG for Apache Tomcat does reference the SecurityManager, making it mandatory for this server.
  • 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.

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.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • SecurityManager isn't bad

    by Cameron Purdy,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Yes, it is complicated, and probably hard to maintain. Yes, it complicates the runtime (compilers, etc.) Yes, most people don't use it.

    But the Java SecurityManager is actually a pretty incredible piece of engineering. It took 15 years of work to get it to work correctly, but in the end, it turned out to be pretty good, with a relatively small performance impact.

    I'm not disagreeing with the decision to deprecate it. The Java team has limited resources, and they have to pour a lot of resources into stuff like this that almost no one uses.

    To be clear, though, WebLogic does support the SecurityManager, and some customers do run with it. Coherence does support the SecurityManager, and some customers do run with it. It's the (10-15%) performance hit that people don't like. And the incompatibilities with almost every useful open source project.

    It takes a huge amount of engineering effort to get useful things to work (let alone work well) with the SecurityManager turned on, which is why open source projects like JBoss and Hazelcast don't support it.

    The answer? Go back in time, and turn on the SecurityManager by default. Then everyone uses it, and nothing gets developed that doesn't work with it. But that ship has sailed, and now the SecurityManager is going to cross the bar as well. How does the poem go? "Sunset, and evening star, and one clear call for me ..."

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT