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

[Alan Bateman]

On 24/03/2017 10:09, Andrew Dinn wrote:

> :
> The point I think Remi is making is that /pragmatically/ we will be back
> in pre-JDK6 land with the current proposed default. You blithely use the
> words 'the launch script can specify' above. In practice, your use of
> the definite article belies the fact that there is not 'a' launch script
> but a plethora of command lines and scripts employed by a multitude of
> users. It is the practical concerns involved in managing the complexity
> that that multiplicity implies I am concerned with. I think I probably
> speak for Remi here too and, perhaps, others agent implementors. I'd
> like to see a much better argument for the security benefits of this
> change before it gets rolled into a release.
>
Just to re-cap, the Attach API has several users:

1. The troubleshooting tools such as jcmd, jstack, and jmap
2. Management tools that use the API to start a JMX agent
3. Tools that load JVM TI or java agents into running VMs.

The proposal here does not impact #1 and #2, this is why I said thaht it 
does not bring us back to JDK 5. Opinions will differ but I think #1 is 
by far the most useful aspect to the attach mechanism.

#3 has always been controversial. The issue in JIRA might be only a few 
days old but the concerns with the dynamic agent loading part go back 
years (more like 10 years). I did the original attach API back in JDK 6 
and regret that the agent loading part wasn't opt-in from the start. 
Yes, it's hard to change it now. In general then we've done a lot of 
changes in JDK 8 and JDK 9 to make the platform more secure by default, 
this fits with that direction. You mentioned in the other mail about the 
mechanism being restricted to same uid/gid but that is also a bit too 
restrictive (there are complaints periodically on this). I expect it 
will have to be relaxed at some point to allow root, users with specific 
capabilities, Windows Terminal Server environments, etc.  In addition, 
the changes in JDK 9 makes it too easy to use the attach API from 
regular applications or libraries - something that was never the 
intention. I don't think it's possible to lock things down from the API 
side of things, it has to be the VM side.

If it is changed to needing to opt-in then the question comes up as to 
how many tools are impacted and what is the impact. I can't say exactly 
how many tools using this API to load code into running VM but it 
doesn't seem to be many. The impact would be that these tools would need 
to document that the VM needs to be launched with the opt-in option in 
order to use the tool in this way.  It shouldn't impact the IDE 
environment too much. Server deployments where profilers are other tools 
would need the CLI option, that could be disruptive to add initially.

-Alan