On 11/7/24 2:06 PM, Mikael Sterner wrote:
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.
Avoiding exposing sensitive information in exceptions is in general a
good practice to consider, and JSCG 2-1 [1] goes into this in more
detail. The risks are considerably greater with untrusted code which is
why you see that code above sanitized when an SM is enabled.
We have introduced a security property in more recent releases named
`jdk.includeInExceptions` [2] which can be used to sanitize exception
messages independent of the SM being enabled. We will take a closer look
at the case above and see if we need to provide additional measures.
--Sean
[1] https://www.oracle.com/java/technologies/javase/seccodeguide.html#2-1
[2]
https://github.com/openjdk/jdk/blob/f2316f6829c9b671e992401ee39d7a1a1805857e/src/java.base/share/conf/security/java.security#L1296
