JEP proposed to target JDK 24: 486: Permanently Disable the Security Manager
Loïc MATHIEU
loikeseke at gmail.com
Wed Nov 6 09:48:35 UTC 2024
So the answer is to create an agent and do whatever I need.
This is a lot of development with very low-level code (bytecode
manipulation) that will not be achievable for every project. Moreover, each
time there is bytecode manipulation, there is a risk that subsequent Java
releases will break the code, making it less robust. There is a risk that
the community will end up with tens of these agents with different
behaviors, creating security holes.
Of course, we can intercept any call with an agent, but for some sensitive
operations, I'm thinking particularly of file system access, this would
have been great to have a builtin mechanism. I can live with plugins
calling System.exit(); it can easily be monitored by standard operational
tools and acted upon. However, file access would be much more complicated
to verify via an agent as there are multiple API (without taking about
cross-platform support), and it would have way more potential security
implications (like accessing configuration files).
Anyway, thanks for your answer,
Loïc
Le mar. 5 nov. 2024 à 19:36, Alex Buckley <alex.buckley at oracle.com> a
écrit :
> On 11/5/2024 9:07 AM, Loïc MATHIEU wrote:
> > 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.
> >
> > 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();
> > }
>
> You're saying that calls to some methods in the Java Platform API (e.g.,
> System.exit) should be disallowed if they come from a plugin. We view
> this as "intercepting" calls to the Java Platform API. We recently
> updated JEP 486 to more clearly address this matter:
>
> https://openjdk.org/jeps/486#Intercepting-calls-to-the-Java-Platform-API
>
> Alex
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20241106/881a9378/attachment.htm>
More information about the jdk-dev
mailing list