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
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
In one of my previous posts, I described how to create a custom policy file for one's application. The process was manual and incremental. Because of that, it was painstakingly long, and hence not really useful. Since I wrote the post, I found a way to write the policy file under in a couple of hours, instead of days.
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