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

[Ron Pressler]

> On 7 Sep 2023, at 20:51, Eric Bresie <ebresie 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?

No, but there is, indeed, a relationship between integrity and security (more here: https://openjdk.org/jeps/8305968) and so between SecurityManager and what we’re discussing here.

You can think of integrity as a generalisation of memory safety (which is, indeed, a set of integrity guarantees, but we want to offer more): You can certainly have memory safety and not have security, but it’s hard to have security without memory safety (though not completely impossible).

Because without integrity it’s very difficult to build any kind of secure code at any layer, we can say that integrity is a prerequisite to (robust) security, and indeed, because SecurityManager aimed to offer security, it also had to offer integrity (which included restricting the use of JNI).

Here we’re interested only in the integrity aspect, but on the other hand integrity, and especially integrity by default, also has important implications other than safety, such as performance (the ability of the platform to optimise code in various ways) and maintainability (the ability of the platform to evolve without affecting clients, i.e. user code). So while there is an intersection between SecurityManager and integrity-by-default, they are not the same, and neither is contained in the other.

— Ron