Code signing [Was: JEP draft: Prepare to Restrict The Use of JNI]

[Remi Forax]

Hello,

> The The JDK itself is implicitly trusted to use JNI. Allowing
>   signed code to do the same gives the user the power to extend that
>   trust.

I like that idea, and i will go a step further, as a provoking thought, given that the JDK does not exist anymore, we have a bunch of modules, why other module than java.base should be alble to access to JNI by default ?

For me, the application should grant each module access to JNI or not, with java.base being granted automatically.

I will move the idea of code signing aside because it's something to ensure the integrity of a module, not something in between modules IMO.

We need a file to list the granted module. Given that an application in Java is defined by its main class, I propose to reuse the module-info.class of the main class to store the list of the modules that can access to JNI by default.
We should also provide a runtime API that is able to grant native access to any module if the code is executed inside the main module (the module of the main class).

This obvisouly does not work if the application is not modular but one can use the runtime API for that, the main module of a non mudular API is the unamed module so any methods inside the unamed module will be able to grant native access. And the launcher should be able to grant access to the main module by calling the runtime API.

But all of this is technical, I think the main important point here is as you said the developer should be able to extend the trust to not only java.base but other modules.

regards,
Rémi

----- Original Message -----
> From: "Andrew Haley" <aph-open at littlepinkcloud.com>
> To: "jdk-dev" <jdk-dev at openjdk.org>
> Sent: Tuesday, September 5, 2023 2:58:56 PM
> Subject: Code signing [Was: JEP draft: Prepare to Restrict The Use of JNI]

> [ I have tried to read all the replies. I hope that I haven't missed anyone
> making this point. ]
> 
> In the "Alternatives" section you write
> 
> > Rather than restrict the loading of native libraries and the binding
> > of native methods, the JVM could apply access control rules when
> > native code uses JNI functions to access Java fields and methods
> 
> Java has facilities that allow code to be cryptographically signed.
> Could not the end user configure, by means of a local permissions
> file, a list of code signers they trust to use JNI? That seems (to me)
> to satisfy the requirement to obtain explicit approval from the end
> user or the application assembler. It also provides an alternative to
> a command-line flag, which I know to be inconvenient and annoying. It
> also allows installers, as well as end users, to control native
> access.
> 
> - Was this idea considered?
> 
> - Is this sort of configury what you meant by "apply access control
>   rules?"
> 
> - Is thre anything wrong with this as an idea? We already have the
>   machinery to sign and verify code sources, and as far as I can see
>   it keeps the control in the hands of the user.
> 
> - The The JDK itself is implicitly trusted to use JNI. Allowing
>   signed code to do the same gives the user the power to extend that
>   trust.
> 
> On 8/21/23 13:41, Ron Pressler wrote:
> >
> > In the future, code that uses JNI will run only if unsafe native
> > access is enabled, and to prepare for that future, JDK 22 should
> > spotlight the use of JNI with warnings. We've published a draft JEP
> > that explains why using JNI is unsafe and describes the warnings
> > [3].
> 
> --
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671