New candidate JEP: 451: Prepare to Disallow the Dynamic Loading of Agents

[Ron Pressler]

Java applications are so much easier and more flexible now than they ever were and can control any aspect of the Java runtime — including its version — thanks to jlink. The end users of your standalone application should not only not care about JVM flags (let alone set them themselves), they no longer need to be aware that the application is written in Java at all. All of the runtime settings are under the control of the application, and you can expose whatever you like to your users.

I don’t understand what security has to do with this.

— Ron

> On 17 May 2023, at 21:13, Jochen Theodorou <blackdrag at gmx.org> wrote:
> 
> On 17.05.23 21:34, Gregg Wonderly wrote:
>> 
>> 
>>> On May 16, 2023, at 12:22 PM, Ron Pressler <ron.pressler at oracle.com> wrote:
>>> 
>>> At the core of your arguments is the claim — that we’ve heard told second-hand but rarely if ever reported first-hand — that the inability to control the command line is common. This claim is very important because its implications go well beyond the relatively niche issue of dynamically loaded agents, so I think it merits further discussion4. Certainly since the discontinuation of the centralised JRE deployment model in JDK 11, it’s been a deep assumption of Java’s design that deploying a Java application requires control of the command line. If you cannot control the command line, there are things you simply cannot do, including much more basic things than loading agents. If your application needs APM, surely it also needs control over the heap and GC with potentially new options.
>> 
>> The first thrust of Java deployment was Applets which used no “command line” and automatically deployed and “secured” the Java environment.  Next was the automatic recognition of .jar files on the Windows environment (file type mapping to invocation already existed) to just run “java -jar file.jar” for the user, without explicit need to use the command line.  Linux added a file type handling in the kernel to make exec(2) able to launch jar files with “java -jar file.jar” without explicit command line use.
> 
> don't forget about  webstart. Now deprecated as well... but you mention
> it later.
> 
> But frankly for me it was always shell scripts or something like that
> starting the Java process. Some "magic" that had to be done here and
> there. And if it is only supplying an exe with icon, or a special
> certificate, that is only valid inside the company....
> 
>> Java “server” deployment still seems like the focus of these conversations with little to no focus on all the other environmental details of how Java was deployed and is still deployed using so many other available mechanisms.
> 
> Many seem to believe that the time for application servers is over and
> you will now have probably microservices, each in its own native
> compiled image. In one of my upcoming projects where I could use
> something like this Java was not the primary candidate. We actually had
> to defend that. Python and Go was what they wanted instead.
> 
> In the end I am speculating and - that goes really completely to Ross
> here - I really would like to know what is the new development model and
> the new deployment model that has been talked about so often here
> already. And also for whom are those?
> 
>>> Those who restrict access to the command line will need to explain their constraints because that approach is already not viable. Deploying a Java application, certainly one that supports super-advanced uses such as the dynamic loading of agents for code manipulation, without control of the command line is not a model that the platform has supported for a while. Java’s deployment model changed some years ago, and policies that applied to the retired model do not apply for the new one and have to change (again, nothing to do with agents).
>> 
>> Running a jar file with a double click using a “default” model has been used “forever.”  I don’t know which “retired model” you are referring to.  Perhaps “applet” and “webstart” and some other mechanisms?
>> 
>> It really is possible to start a Java application without any command line use still today.
> 
> For me writing an application that requires my users to use the command
> line means a loss of users. So then it would probably work like this...
> I implement a mechanism by which a plugin for my application can tell me
> what command line options it needs and I change a "starter" that will
> then supply them. All automatic, the user will not see anything and
> security is just as bad as ever
> 
> Applications just seem not to be a viable target anymore
> 
> bye Jochen
> 
>