JVM security Spring Boot policy

Proposal for a Java policy files crafting process

I’ve already written about the JVM security manager, and why it should be used - despite it being rarely the case, if ever. However, just advocating for it won’t change the harsh reality unless some guidelines are provided to do so. This post has the ambition to be the basis of such guidelines. As a reminder, the JVM can run in two different modes, standard and sandboxed. In the former, all API are available with no restriction; in the later, some API calls deemed sensitive are forb

JVM security JAR Spring Boot policy

Signing and verifying a standalone JAR

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 -genke

security Attach API JMX JConsole

Beware the Attach API

A post brought to light an interesting feature of the JDK I didn’t know about: the ability to update a code running in a JVM. The referenced post shows how to apply a bugfix using that feature. The devious white hat JVM hacker in me started to think how one could apply that trick for other less beneficial purposes. And of course, how to prevent that. Hack overview Let’s imagine a banking application based on the familiar Spring Boot stack. A TransferService class is dedicated to