deprecation of SecurityManager JEP 411

[Bowes, David]

Unfortunately I have to completely disagree with deprecating the SecurityManager: JEP411


“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.

The threat of malicious intent by remote code has receded because the Java Platform no longer supports applets. The Applet API was deprecated in Java 9 in 2017<https://openjdk.java.net/jeps/289>, then deprecated for removal in Java 17 in 2021<https://openjdk.java.net/jeps/398> with the intent to remove it in a future release. The closed-source browser plugin that ran applets was removed from Oracle's JDK 11 in 2018<https://www.oracle.com/technetwork/java/javase/javaclientroadmapupdatev2020may-6548840.pdf#%5B%7B%22num%22%3A34%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C93%2C665%2C0%5D> along with the closed-source Java Web Start technology<https://www.oracle.com/technetwork/java/javase/javaclientroadmapupdatev2020may-6548840.pdf#%5B%7B%22num%22%3A34%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C93%2C504%2C0%5D>. Accordingly, many of the risks that the Security Manager protects against are no longer significant. Furthermore, the Security Manager cannot protect against many risks that now are significant. The Security Manager cannot address 19 of the 25 most dangerous issues identified by industry leaders in 2020<https://cwe.mitre.org/top25/archive/2020/2020_cwe_top25.html>, so issues such as XML external entity reference (XXE) injection and improper input validation have required direct countermeasures in the Java class libraries. (For example, JAXP can protect against XXE attacks and XML entity expansion<https://docs.oracle.com/en/java/javase/16/security/java-api-xml-processing-jaxp-security-guide.html#GUID-D97A1F1D-8DDF-4D19-A7E5-99099F27346E>, while serialization filtering<https://docs.oracle.com/en/java/javase/16/core/serialization-filtering1.html#GUID-3ECB288D-E5BD-4412-892F-E9BB11D4C98A> can prevent malicious data from being deserialized before it can do any damage.) The Security Manager is also incapable of preventing malicious behavior based on speculative-execution vulnerabilities<https://mail.openjdk.java.net/pipermail/vuln-announce/2019-July/000002.html>.
“

I used the SecurityManger with great success to protect against Log4JShell.

It helped me identify the permissions being requested and then the stack track where certain patterns of permission requests were occurring.  The SecurityManager rules were then added to  prevent the vulnerability.  It is the basic of active research into behaviour based attacks.

None of the techniques you describe above which ‘replace’ the SecurityManager functionality were sufficient.  I would suggest that the SecurityManager does protect me from singinficant threats.

Davd Bowes




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20220123/7e6b5ba7/attachment.htm>