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

[Andrew Haley]

[ 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