JEP 486: Secondary effects of having a security manager installed?

[Mikael Sterner]

Hi!

I miss a more complete discussion in JEP 486 about the secondary effects
of having a security manager installed other than achieving sandboxing,
if they should be possible to achieve when a security manager cannot be
installed or if they should be considered as not important going forward.

For example, there seems to have been an ambition to reduce information leakage
in exceptions when a security manager is enabled, indicated by this comment and
behavior:
https://github.com/openjdk/jdk/blob/f2316f6829c9b671e992401ee39d7a1a1805857e/src/java.base/share/classes/java/nio/file/TempFileHelper.java#L127

The scenario I have in mind is transforming an application, that currently uses
the security manager for sandboxing of untrusted code, to instead use OS level
sandboxing, which in itself seems straightforward. Should such an application
now consider exposing exception details as more prone to information leakage?
Or will there in general be a way to keep those information leakage mitigations
in place, to not have to make an active security decision here?

Maybe the ambition to reduce information leakage with a security manager enabled
was never documented, and maybe it wasn't very effective. Maybe exposing
exception details always carried such a big information leakage risk that the
few mitigations never made a practical difference. Either way it would be good
to discuss it in relation to JEP 486 to guide developers transitioning from
having a security manager enabled.

Yours,
Mikael Sterner