All,
In watching the responses to log4shell, I'm reminded again of how
useful the SecurityManager can be. It didn't completely save
Elasticsearch from having to upgrade immediately, but it did provide
some really important protections. I haven't worked with the
SecurityManager much except a bit of toe-stubbing here and there so my
knowledge is limited.
>From what I can tell:
Pros:
* can protect against parsers behaving badly: network calls, data
exfiltration, system.exit, rce
Cons:
* Slated to be deprecated in Java 17 (active support ends in 2026,
security support in 2031) and then go away [1]
* Adds complexity to our own code
* Adds complexity to users with custom parsers -- how easy will it be
to modify the security policies for users with their own custom
parsers that make network calls and read/write from non-standard
directories.
* Can't protect against infinite loops/timeouts (still need process
level isolation)
* To protect against log4shell level vulns, it would have to apply to
the entire application, not just parsing+detection.
Is this something worth pursuing? Are there things we can do with the
SecurityManager or via other techniques to improve the robustness of
our codebase?
Cheers,
Tim
[1] https://openjdk.java.net/jeps/411
