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
