JEP proposed to target JDK 24: 486: Permanently Disable the Security Manager

[Loïc MATHIEU]

Hi,

I already sent this feedback to this mailing list without an answer, so I'm
not sure if my first message was successfully delivered.
In doubt I'll resend it.

I work for Kestra, a data orchestrator: https://www.kestra.io.

Kestra handles workflows made of tasks and triggers, both of which are
plugins. We provide more than 500 plugins, but users can also bring their
own plugins in the form of JARs they put in a specific directory.

Our plugin mechanism includes security features using the Security Manager,
this is important as administrators need to be sure that plugins behave
securely; our security checks are:
- A plugin cannot start new threads
- A plugin cannot start new processes
- A plugin cannot exit the VM
- A plugin cannot read files out of its working directory

This feature can be configured with allowed plugins / forbidden plugins to
be able to cherry-pick which plugin is allowed to perform those actions or
not.

As most plugins are written in Java and installed by administrators, we
also have some plugins that allow running scripts (Nashorn, Jython,
Groovy), which we cannot control by nature.

We currently run in Java 21, but if the Security Manager is removed, it
would be difficult for us to use Java 24+ as it would mean giving up some
security features that our users rely on (including ourselves in our
work-in-progress SaaS offering).

I understand that the current implementation of the SecurityManager is not
ideal, but I would love a replacement, at least for parts of what it offers
today.

On top of my mind, but I know that if a replacement would be created, it
would not be that one; something close to what we have with
structured concurrency would be great:
t
ry
(SecurityScope.allowNewThread(false).allowNewProcesses(false).canExitVM(false).allowFileAccess(fileName
-> file.startWith(workingDir)) {
    // run the plugin code
    plugin.run();
}

I know that other people have already asked to restrict, for example,
exiting the VM. Other tools also have a plugin system and a security
manager (like Elasticsearch), so despite what is said in this JEP, the
Security Manager is still used. Removing it without any replacement, at
least for part of its mechanism, would lower the security of the Java
platform for those using it.

Regards,

Loïc

Le ven. 1 nov. 2024 à 19:29, Mark Reinhold <mark.reinhold at oracle.com> a
écrit :

> The following JEP is proposed to target JDK 24:
>
>   486: Permanently Disable the Security Manager
>        https://openjdk.org/jeps/486
>
>   Summary: The Security Manager has not been the primary means of
>   securing client-side Java code for many years, it has rarely been used
>   to secure server-side code, and it is costly to maintain.  We therefore
>   deprecated it for removal in Java 17 via JEP 411 (2021).  As the next
>   step toward removing the Security Manager, we will revise the Java
>   Platform specification so that developers cannot enable it and other
>   Platform classes do not refer to it.  This change will have no impact
>   on the vast majority of applications, libraries, and tools.  We will
>   remove the Security Manager API in a future release.
>
> Feedback on this proposal from JDK Project Committers and Reviewers [1]
> is more than welcome, as are reasoned objections.  If no such objections
> are raised by 20:00 UTC on Friday, 8 November, or if they’re raised and
> then satisfactorily answered, then per the JEP 2.0 process proposal [2]
> I’ll target this JEP to JDK 24.
>
> - Mark
>
>
> [1] https://openjdk.org/census#jdk
> [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20241105/975c5a0c/attachment.htm>