<div dir="ltr">Hi,<div><br></div><div>I already sent this feedback to this mailing list without an answer, so I'm not sure if my first message was successfully delivered. </div><div>In doubt I'll resend it.</div><div><br></div><div>I work for Kestra, a data orchestrator: <a href="https://www.kestra.io/" target="_blank">https://www.kestra.io</a>.</div><div><br></div><div>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.<br><br></div><div>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:</div><div>- A plugin cannot start new threads</div><div>- A plugin cannot start new processes</div><div>- A plugin cannot exit the VM</div><div>- A plugin cannot read files out of its working directory</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>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:<br>t</div><div>ry (SecurityScope.allowNewThread(false).allowNewProcesses(false).canExitVM(false).allowFileAccess(fileName -> file.startWith(workingDir)) {<br> // run the plugin code<br> plugin.run();<br>}</div><div><br></div><div>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.</div><div><br></div><div>Regards,</div><div><br></div><div>Loïc</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 1 nov. 2024 à 19:29, Mark Reinhold <<a href="mailto:mark.reinhold@oracle.com">mark.reinhold@oracle.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The following JEP is proposed to target JDK 24:<br>
<br>
486: Permanently Disable the Security Manager<br>
<a href="https://openjdk.org/jeps/486" rel="noreferrer" target="_blank">https://openjdk.org/jeps/486</a><br>
<br>
Summary: The Security Manager has not been the primary means of<br>
securing client-side Java code for many years, it has rarely been used<br>
to secure server-side code, and it is costly to maintain. We therefore<br>
deprecated it for removal in Java 17 via JEP 411 (2021). As the next<br>
step toward removing the Security Manager, we will revise the Java<br>
Platform specification so that developers cannot enable it and other<br>
Platform classes do not refer to it. This change will have no impact<br>
on the vast majority of applications, libraries, and tools. We will<br>
remove the Security Manager API in a future release.<br>
<br>
Feedback on this proposal from JDK Project Committers and Reviewers [1]<br>
is more than welcome, as are reasoned objections. If no such objections<br>
are raised by 20:00 UTC on Friday, 8 November, or if they’re raised and<br>
then satisfactorily answered, then per the JEP 2.0 process proposal [2]<br>
I’ll target this JEP to JDK 24.<br>
<br>
- Mark<br>
<br>
<br>
[1] <a href="https://openjdk.org/census#jdk" rel="noreferrer" target="_blank">https://openjdk.org/census#jdk</a><br>
[2] <a href="https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html" rel="noreferrer" target="_blank">https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html</a></blockquote></div>