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

[Attila Kelemen]

If I'm understanding you correctly, then this proposal wants to be able to
allow native access to the jars of a particular vendor. That would be
actually useful to us, because at the moment we have some jars using native
libraries, and a problem with these libraries is that they are split into a
lot of small jars (all making native calls), and not everyone uses the same
subset of these jars. Though I might have to repackage them anyway (even
though they are not managed by me), but if I didn't need to merge them into
a single module that would be better. And since they are all accessing the
same set of native libraries (they are just split into many small jars for
whatever reason), it is not useful to give access to them separately.

However, why would we need a signature for this? If some of the jars are
malicious, then we are screwed even with Java only. If they are not
malicious then a simple manifest entry (or a combination of multiple) for
the group seems enough. For example, it would be enough I think, if we
could enable native access on the basis of some manifest entries, like
writing
`--enable-native-by-manifest="Vendor=MyCompany,Native-Libs=my-native-libs"`
(where both "Vendor" and "Native-Libs" would be a key in the manifest).

Andrew Haley <aph-open at littlepinkcloud.com> ezt írta (időpont: 2023. szept.
5., K, 14:59):

> [ 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20230906/7651f677/attachment-0001.htm>