PRE-RFR: 8177154: Default configuration should disallow loading agents

[Andrew Dinn]

I don't have any specific objection to this patch, per se. However, as
an implementor of an agent which uses the dynamic load capability of the
JVM I wish to raise an objection to making any such change. I would
certainly like more time for discussion before it gets pushed through
into a release (I note it was only raised 3 days ago)

I am happy to have the ability to be able to configure dynamic loading
as a separate step from enabling agent loading. However, I would prefer
the default behaviour for dynamic loading to be that where attach is
allowed by default. I say that not as a personal preference but because
retaining that default is very important for the large number of users
in Red Hat's customer base who use my agent and may well be important
for users of other agents.

Of course, I understand that the change is not removing any
functionality. However, it does mean that users have to remember to set
the relevant flag in test and, possibly, in production in order to be
able to employ an agent ad hoc (indeed, I think the requirement to do so
makes it clear that the latter term no longer applies with this change).

ad hoc agent usage as a default option is considered extremely important
by Red Hat's support team. Our opposition to this change arises because
in order to allow such agent usage to continue it will i) require us to
re-educate all our users on use of the relevant command line option and
ii) require them to have to modify startup configurations when they wish
to switch between earlier and later JDK releases (in either direction).

The declared motive for this change to default to forbidding dynamic
loading is security. However, I find that to be dubious. Assuming that
the default were reversed, the opportunity to load an agent via the
VM_Attach API requires either i) hostile code already to be running in
the current JDK runtime or ii) the command line on the host machine to
have been compromised. Basically, it is already game over before any use
of this specific vector becomes available. The only real difference this
change might make is to allows a major compromise to be escalated
quicker. I would really like to hear a much better argument than simply
'[we are] making the platform more secure by default' to justify the
adoption of this default.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

On 24/03/17 08:45, serguei.spitsyn at oracle.com wrote:
> Please, pre-review the JDK 9 fix for:
>   https://bugs.openjdk.java.net/browse/JDK-8177154
> 
> 
> JDK webrev:
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8177154-agents.jdk0/
> 
> 
> Hotspot webrev:
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8177154-agents.hs0/
> 
> 
> Hotspot test/closed webrev:
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8177154-agents.nsk0/
> 
> 
> 
> Summary:
>   Please, see the bug report of this Enhancement.
> 
>   As part of making the platform more secure by default we re-examine
> the ability to load
>   arbitrary code (both native and java) into a running VM with the
> attach mechanism.
> This issue tracks changing the VM side of the attach mechanism to
> disallow the "load"
>   command by default. The "load" command is what the
> VirtualMachine.loadAgentXXX methods
>   use to load java and JVM TI agents into the target VM.
>   A non-manageable command line flag -XX:+EnableDynamicAgentLoading is
> introduced to allow
>   opt-in and allow agents to be loaded.
>   Note that the VM already has -XX:+DisableAttachMechanism to completely
> disable the attach mechanism
>   but that disables it completely and prevents the use of the
> cooperative troubleshooting tools.
> 
>   A few notes on the proposal:
> 1. It should have no impact on command-line/troubleshooting tools.
> 2. It should have no impact on tools that start the JMX agent with the
> attach mechanism.
> 3. No impact on the JVM TI or java.lang.instrument specifications as
> Java SE does not specify
>       the mechanism, it just allows for the possibility of agents being
> loaded in a running VM.
> 4. The changes to implement this are likely to be small and low-risk.
>       The main thing is to make sure that the error on the attach API
> side is useful.
>       A small number of existing tests will need to be updated to run
> with the new XX option.
>    5. The change should only impact a small number of tools but it will
> need to be documented
>       in the JDK 9 release notes.
> 
>   It will require filing a CCC and a release notes update.
> 
>   At this stage, I'd like to make sure the whole direction of the changes
>   is right and nothing important is missed.
> 
> 
> Testing:
>   This was tested with the tests:
>     - nsk.aod
>     - nsk.jvmti AttachOnDemand
>     - nsk.monitoring
>     - jdk/test/com/sun/tools/attach
>     - jdk/test/java/lang/management
>     - jdk/test/sun/tools
>     - jdk/test/closed/javax/management
>     - jdk/test/closed/com/sun/jmx
>     - jdk/test/closed/com/oracle/jfr
> 
>    Please, let me know if any other test suites are necessary to run.
>    Q1: Have I missed any attach test suites?
>    Q2: What are the best ways to run all management and jmx test?
>    Q3: The same question is about the J*tools tests.
> 
> 
> Thanks,
> Serguei
>