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

[Jack Shirazi]

Thank  you for your reply. This makes it clear that the JEP has a single 
specific tradeoff. So we have two capabilities at issue here

A) Currently libraries can turn themselves into agents

B) Currently agents can remotely attach

The JEP has decided for the community that each of these are a bad thing 
and should be disabled by default (though enableable by setting an 
option). My involvement in community discussions over the years has been 
that no one complains about (A), it has not been used maliciously, and 
there is a small niche who use it. (B) is used quite a lot and enhances 
JVM serviceability with a capability that is a clear advantage over 
other runtimes. It seems a shame to eliminate that competitive advantage.

The JEP clearly points out that anyone concerned by these can disable 
the ability with a simple command-line option, so there is a simple 
solution for this minority. The fundamental error is really that the 
attaching agent is read-write rather than read-only. If we could change 
that, it would be ideal, but sadly I don't think that's easily doable.

I and many in the monitoring community believe this JEP is NOT an 
enhancement to the JDK. The proposers believe it is. Is there a 
mechanism other than this email discussion list to gain wider community 
feedback so we can ascertain if there is really a strong community 
preference either way?


On 11/05/2023 19:37, Ron Pressler wrote:
> The general policy in effect since JEP 261 [1] was delivered in JDK 17 (and included the dynamic agents change) is that the application and not libraries gets to decide what encapsulation-bypassing mechanisms are allowed. In the case of agents, JEP 451 states:
>
>> To ensure that the owner of an application approved the use of agents, JDK 5 required agents to be specified on the command line with the -javaagent or -agentlib options, and loaded the agents immediately at startup. This represented an explicit grant of privileges by the application owner.
> This is in line with the policy; letting libraries decide that they want to deploy an encapsulation-bypassing agent without the applications explicit consent is not. The full motivation behind the policy, and what integrity (not to be confused with security) means, is explained in this information JEP draft: https://openjdk.org/jeps/8305968
>
> [1]: https://openjdk.org/jeps/261
>
>> On 11 May 2023, at 11:11, Jack Shirazi <jacks at fasterj.com> wrote:
>>
>> This proposes to deprecate one mechanism for agent loading, but the ability to run an agent in the JVM is unchanged. This means that if disallowed in future, there will still be absolutely no change in "the balance between serviceability, which involves ad-hoc changes to running code, and integrity, which assumes that running code is not arbitrarily changed". Applying the deprecation will still leave the exact same ability for arbitrary changes to the code.
>>
>> For libraries that may use this mechanism, I checked the https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=java CVEs for the last five years and can't find any recorded abuse of it. I find it hard to believe that developers wouldn't know that their dependencies use this, if they do.
>>
>> Ultimately, integrity may be preferred, but there is a balance. For example we are not proposing to remove java agent capability, reflection, dynamic class loading, etc, all of which in one way or another violate integrity, because these are features which make the JVM hugely successful.
>>
>> I don't see the benefit here. What future improvement would happen if the deprecation is subsequently applied?
>>
>> On 08/05/2023 20:17, Mark Reinhold wrote:
>>> https://openjdk.org/jeps/451
>>>
>>>    Summary: Issue warnings when agents are loaded dynamically into a
>>>    running JVM. These warnings aim to prepare users for a future release
>>>    which disallows the dynamic loading of agents by default in order to
>>>    improve integrity by default. Serviceability tools that load agents at
>>>    startup will not cause warnings to be issued in any release.
>>>
>>> - Mark