:revdate: 2017-02-05 16:00:00 +0100 :page-liquid: :icons: font :experimental:

link:{% post_url 2017-02-05-proposal-java-policy-files-crafting-process %}[Last week^], I wrote about the JVM policy file that explicitly lists allowed sensitive API calls when running the JVM in sandboxed mode. This week, I’d like to improve the security by signing the JAR.

== The nominal way

This way doesn’t work. Readers more interested in the solution than the process should skip it. **

=== Create a keystore

The initial step is to create a keystore if none is already available. There are plenty of online tutorials showing how to do that.


keytool -genkey -keyalg RSA -alias selfsigned -keystore /path/to/keystore.jks -storepass password -validity 360 —-

Fill in information accordingly.

=== Sign the application JAR

Signing the application JAR must be part of the build process. With Maven, the[JAR signer plugin^] is dedicated to that. Its usage is quite straightforward:


maven-jarsigner-plugin 1.4 sign sign /path/to/keystore.jks selfsigned ${store.password} ${key.password}

To create the JAR, invoke the usual command-line and pass both passwords as system properties:


mvn package -Dstore.password=password -Dkey.password=password —-

Alternatively, Maven’s[encryption capabilities^] can be used to store passwords in a dedicated settings-security.xml to further improve security.

=== Configure the policy file

Once the JAR is signed, the policy file can be updated to make use of it. This requires only the following configuration steps:

  1. Point to the keystore
  2. Configure the allowed alias


keystore “keystore.jks”;

grant signedBy “selfsigned” codeBase “file:target/spring-petclinic-1.4.2.jar” { … } —-

Notice the signedBy keyword followed by the alias name - the same one as in the keystore above.

=== Launching the JAR with the policy file

The same launch command can be used without any change:


java -jar target/spring-petclinic-1.4.2.jar —-

Unfortunately, it doesn’t work though this particular permission had already been configured!


Caused by: access denied (“java.lang.reflect.ReflectPermission” “suppressAccessChecks”) at at at java.lang.SecurityManager.checkPermission( at java.lang.reflect.AccessibleObject.setAccessible( at org.springframework.util.ReflectionUtils.makeAccessible( at org.springframework.beans.BeanUtils.instantiateClass( at org.springframework.boot.SpringApplication.createSpringFactoriesInstances( —-

The strangest part is that permissions requested before this one work all right. The reason is to be found in the particular structure of the JAR created by the Spring Boot plugin: JAR dependencies are packaged untouched in a BOOT-INF/lib folder in the executable JAR. Then Spring Boot code uses custom class-loading magic to load required classes from there.

JAR signing works by creating a specific hash for each class, and by writing them into the JAR manifest file. During the verification phase, the hash of a class is computed and compared to the hash of the manifest. Hence, permissions related to classes located in the BOOT-INF/classes folder work as expected.

However, the org.springframework.boot.SpringApplication class mentioned in the stack trace above is part of the spring-boot.jar located under BOOT-INF/lib: verification fails as there’s no hash available for the class in the manifest.

Thus, usage of the Spring Boot plugin for JAR creation/launch is not compatible with JAR signing.

== The workaround

Aside from Spring Boot, there’s a legacy way to create standalone JARs: the[Maven Shade plugin^]. This will extract every class of every dependency in the final JAR. This is possible with Spring Boot apps, but it requires some slight changes to the POM:

  1. In the POM, remove the Spring Boot Maven plugin
  2. Configure the main class in the Maven JAR plugin: + [source,xml] —-
maven-jar-plugin 3.0.2 org.springframework.samples.petclinic.PetClinicApplication
  1. Finally, add the Maven Shade plugin to work its magic: + [source,xml] —-
maven-shade-plugin 2.4.3 true package shade

WARNING: The command-line to launch the JAR doesn’t change but permissions depend on the executed code, coupled to the JAR structure. Hence, the policy file should be slightly modified.

== Lessons learned

While it requires to be a little creative, it’s entirely possible to sign Spring Boot JARs by using the same techniques as for any other JARs.

To go further:

  •[Jarsigner Plugin^]
  •[Shade Plugin^]
  •[Spring Boot plugin^]
  •[Spring Boot executable JAR format^]