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

[Ron Pressler]

Hi.

We have not considered that idea, but before I ask you something about it, let me point out a couple of things:

First, the thing that decides to grant JNI privileges is not the JDK but the executable you’re running, i.e. the launcher. If you’re running stock `java`, then it grants the privileges to the modules it knows, which are the JDK modules. If you’re running an application launcher, then it grants the privileges to whichever modules it wants to. You can even create a shared, general `javaplus` launcher that grants privileges to additional modules.

Second, the question is not one of trust. Every application needs to decide whether it wants to be in a mode where those invariants that the JDK wants to maintain hold, or whether certain libraries may change which of those invariants hold. In concrete terms, every application decides whether it runs in a mode where JNI can be used or not. The assumption is that all code you run is trusted to be benevolent (in terms of security, benevolent code is actually far more dangerous than untrusted, potentially malevolent, code because the latter is easy to deal with — except maybe when it comes to supply chain attacks — but I’m digressing).

My question is this: We’ve heard from a few people that configuring the JDK is difficult for them (or perhaps they think it may be difficult for others). What you’re proposing seems to be simply a different kind of configuration. Are you trying to address the configuration difficulty issue or something else? If it’s something else, what is it?

— Ron

> On 5 Sep 2023, at 13:58, Andrew Haley <aph-open at littlepinkcloud.com> wrote:
> 
> [ 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
> 
>