Security Manager [Was: JEP draft: Prepare to Restrict The Use of JNI]

[Michał Kłeczek]

While I appreciate the motivation of this is different than that of SecurityManager, let’s not pretend we are doing something conceptually different.

At the end of the day what we are doing is:
Granting permissions to perform certain actions to specific software components.

The difference is that SecurityManager tried to do it in a principled way that covered broader set of use cases.
And while widely considered as unsuccessful, SecurityManager was important in guarding against vulnerabilities (log4shell for example) for people that used it.

And here we are: we say “SecurityManager is worthless because it is not used”, we dismiss the idea of turning it on by default (which would be painful for sure), but at the same time decide to enforce this pain in a very specific circumstances.

My 2 cents

—

Michal 


> On 7 Sep 2023, at 22:21, Attila Kelemen <attila.kelemen85 at gmail.com> wrote:
> 
>> Just observing the discussion and no expert but…
>> 
>> It sounds like this is about security and restrictions of native libraries.  
>> 
>> Not saying it’s any better or worse but wasn’t that what the depreciated/removed SecurityManager expected to do?
> 
> The JEP is not about security (pure Java code can wreak just as much havoc on the system as native calls). It is simply knowing what your application is attempting to use, and if some of your application's modules are using native calls, then - as the JEP currently states - you have to explicitly acknowledge the fact (for each module). Though the JEP motivation is a little different, to me the benefit of such explicit acknowledgment is that I know that there is some additional requirement for some modules, because native calls might have some expectation on the environment (besides what the JDK needs which is always expected), and I have to fulfill those expectation.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20230908/c4c8203e/attachment.htm>