A possible JEP to replace SecurityManager after JEP 411

[Mario Torre]

On Mon, Apr 25, 2022 at 2:55 PM David Lloyd <david.lloyd at redhat.com> 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. In absolute terms, using a security manager (even with all of
> its problems) is *more* secure than not using it on the same code base
> and deployment. I'm not sure how this can be rationally refuted. The
> proposal is about retaining this incremental increase in security,
> while both adjusting the user's expectations via documentation *and*
> significantly reducing the burden of CVEs and maintenance on the JDK
> itself (and putting it on to the third party authorization framework),
> which in my estimation is the *real* stakes here.

I think there's a difference between "perceived" security and "actual" one.

The SM in today's post Spectre, Meltdown and the likes world is
"perceived" security, which may lead to a relaxation on the security
of other layers because at least "we have additional security
checkpoints in the JDK".

Cheers,
Mario

-- 
Mario Torre
Manager, Software Engineering, core OpenJDK
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898