New candidate JEP: 486: Permanently Disable the Security Manager

[Loïc MATHIEU]

Hi,

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 part 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:
try
(SecurityScope.allowNewThread(false).allowNewProcesses(false).canExitVM(false).allowFileAccess(fileName
-> file.startWith(workingDir)) {
    // run the plugin code
    plugin.run();
}

I know that other people already ask 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

PS: Sorry Mark Reinhold, I first only respond to you only so I resend to all

Le jeu. 26 sept. 2024 à 13:55, Mark Reinhold <mark.reinhold at oracle.com> a
écrit :

> // Correcting Sean’s e-mail address
>
> 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.
>
> - Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20241011/de6c5f9f/attachment.htm>