A possible JEP to replace SecurityManager after JEP 411

[Alan Bateman]

On 25/04/2022 13:53, David Lloyd wrote:
> Nothing in the proposal causes splitting or delegation of
> responsibilities. It is _only_ about preserving security checkpoints
> in the JDK, which *add* a layer of checks to what the container might
> already provide. Nothing is being subtracted, and thus I find it hard
> to accept that preserving these checks somehow reduces security
> overall.

"preserving security checkpoints in the JDK" suggests just leaving the 
calls do AccessController.doPrivileged and 
SecurityManager.checkPermission in place. That amounts to putting a tax 
on every feature, every JEP, and all ongoing maintenance of the 
platform. If there is refactoring or a change that forgets to insert a 
checkPermission somewhere then we have a security issue and everything 
that goes along with that. No thanks!

I think Martin is right that hooking authorization libraries into low 
level libraries isn't the right way to do this. Aside from the 
complexity methods I would add that threads pools or any hand-off 
between threads will typically break when the context is not carried.

One other point about authorization libraries wanting to hook into low 
level code is that it's a minefield of potential issues with recursive 
initialization, stack overflows and some really hard to diagnose issues. 
JDK-8155659 [1] is one report that comes to mind.

-Alan

[1] https://bugs.openjdk.java.net/browse/JDK-8155659