Furthermore, the Security Manager cannot protect against many risks that now are significant. Accordingly, many of the risks that the Security Manager protects against are no longer significant. The closed-source browser plugin that ran applets was removed from Oracle's JDK 11 in 2018 along with the closed-source Java Web Start technology. The Applet API was deprecated in Java 9 in 2017, then deprecated for removal in Java 17 in 2021 with the intent to remove it in a future release.
REASON CORE SECURITY REMOVAL CODE
The threat of malicious intent by remote code has receded because the Java Platform no longer supports applets. The Security Manager, then, had ambitions to protect against two kinds of threat: Malicious intent, especially in remote code, and accidental vulnerabilities, especially in local code. Limiting permissions was seen as a way to constrain the impact of any vulnerabilities that might exist in a body of code - in effect, a defense-in-depth mechanism. In theory, an application JAR on the class path might be more limited in how it uses the JDK than an applet from the Internet. Allowing all trusted code to access all resources was undesirable, so in Java 1.2 we redesigned the Security Manager to focus on applying the principle of least privilege: All code would be treated as untrusted by default, subject to sandbox-style controls that prevented access to resources, and users would place trust in specific codebases by granting them specific permissions to access specific resources. Simultaneously, the Java class libraries were expanding rapidly - Java 1.1 introduced JavaBeans, JDBC, Reflection, RMI, and Serialization - which meant that trusted code gained access to significant new resources such as database connections, RMI servers, and reflective objects. The Security Manager drew a bright line between untrusted code (applets from a remote machine) and trusted code (classes on the local machine): It would approve all operations involving resource access for trusted code but reject them for untrusted code.Īs interest in Java grew, we introduced signed applets to allow the Security Manager to place trust in remote code, thereby allowing applets to access the same resources as local code run via java on the command line. The small size of the Java class libraries - only eight java.* packages in Java 1.0 - made it feasible for code in, e.g., java.io to consult with the Security Manager before performing any operation. In the era of Java applets downloaded by web browsers, the Security Manager protected the integrity of users' machines and the confidentiality of their data by running applets in a sandbox, which denied access to resources such as the file system or the network. One long-time element of security is the Security Manager, which dates from Java 1.0.
REASON CORE SECURITY REMOVAL UPDATE
Security is a dynamic science, thus we continuously update the Java Platform to address new vulnerabilities and to reflect new industry postures, for example by deprecating weak cryptographic protocols. Meanwhile, the confidentiality of data is protected by the Java class libraries' trusted implementations of modern cryptographic algorithms and protocols such as SHA-3, EdDSA, and TLS 1.3. The integrity of data is protected by the Java language and VM's built-in memory safety: Variables are initialized before use, array bounds are checked, and memory deallocation is completely automatic. Future JEPs or enhancements may define new APIs or mechanisms for specific use cases, depending upon demand. It is not a goal to provide a replacement for the Security Manager. Warn users if their Java applications rely on the Security Manager.Įvaluate whether new APIs or mechanisms are needed to address specific narrow use cases for which the Security Manager has been employed, such as blocking System::exit. Prepare developers for the removal of the Security Manager in a future version of Java.
To move Java forward, we intend to deprecate the Security Manager for removal in concert with the legacy Applet API ( JEP 398). It has not been the primary means of securing client-side Java code for many years, and it has rarely been used to secure server-side code. The Security Manager dates from Java 1.0. Deprecate the Security Manager for removal in a future release.
0 kommentar(er)
