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

[Sean Mullan]

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