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

[Mario Torre]

On Wed, Sep 6, 2023 at 10:34 AM Ron Pressler <ron.pressler at oracle.com> wrote:
>
> 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?

Not answering for Andrew, but I think that tying access control to a
cryptographically signed binary rather than a command line flag seems
more robust, it shift the knowledge of the launcher (granting the
privileges to the modules it knows) toward the actual library
(granting the privileges to the modules that are signed), it also work
well within FIPS environments since then additional restrictions can
be implemented if necessary (like only trusting certain algorithms
etc..).

You are right it's a different kind of configuration, but it seems
worthy of being considered.

Cheers,
Mario
-- 
Mario Torre
Manager, Software Engineering, Red Hat OpenJDK, Java Champion
https://keybase.io/neugens
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
Mastodon: https://mastodon.social/@MarioTorre

Red Hat GmbH, Registered seat: Werner von Siemens Ring 12, D-85630
Grasbrunn, Germany

Commercial register: Amtsgericht Muenchen/Munich, HRB 153243,
Managing Directors: Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross