RFR: 8307478: Implementation of Prepare to Restrict The Dynamic Loading of Agents [v5]

[Ron Pressler]

> On 28 May 2023, at 17:25, Kirk Pepperdine <kirk at kodewerk.com> wrote:
> 
> 
> Call me dumb.. but… I would have the say that the most puzzling piece of this entire JEP/proposal is that I’m failing to make the connect between how an agent is loaded and how that strengthens integrity. I keep re-reading this JEP looking for clues but I keep bumping my head again… "Giving free reign to tools would imply giving free reign to libraries, which is tantamount to giving up on integrity by default.”. IMO, this is a false equivalency that is not supported by any other point in the document. IOWs, there is nothing in this document that is giving me a clue as to how turning off dynamic attach improves integrity when I can achieve the same effects with a direct attach.

You can’t find the answer to your question in 451 because we factored out the motivation for 451 (and several other integrated and future JEPs) into the informational JEP, https://openjdk.org/jeps/8305968, which you must read to understand the motivation.

In short, the goal is integrity *by default*, which means that what we seek not an end to “superpowers" but the explicit granting of superpowers on the command line. The problem is not superpowers, but superpowers that *are not explicitly acknowledged by the application*. Agents loaded at startup have always been explicitly acknowledged by the application, while those loaded after startup have not. The goal is to make them explicitly acknowledged, not “turned off”, and then you get the same for both ways of loading agents: the application explicitly grants superpowers in both situations. We want the capabilities offered by agents, and we want the application to be able to track them.

> What I do know is that turning off dynamic attach by default will cause grief to those that already having to cope with exceptionally complex deployment. I would argue that the complexity of these deployments have dramatically increased since 2017. Do we really want to add to that complexity or should we be refocusing on adding features that help to reduce that complexity.

As the informational JEP explains, not having integrity BY DEFAULT, causes grief too. Do or don’t, someone gets grief. Given that the vast majority of Java programs never require or want agents — attached dynamically or otherwise — given that many current uses of dynamically loaded agents are better served by agents loaded at startup, and given that we have adding a command line flag on the one hand vs not having integrity by default that makes it impossible for applications to know the “map” of their codebase (see the informational JEP), we believe that, when integrated over the entire ecosystem, more grief is caused by not restricting dynamically loaded agents than by restricting it.

— Ron