How to become a "cooperative troubleshooting tool"?

[Gregg Wonderly]

There has been some discussion on this list which I have never been satisfied with around why the SecurityManager was not used for a large number of the things that are being done with literal JVM changes.  Mark Reinhold and others, I believe, don’t know how to use the SecurityManager, or believe that it’s not sufficient for security, even though it has Security in its name.

If the JVM is already compromised in security, even with a SecurityManager in place, it would be nice for Oracle to announce this and provide a solution.  What seems interesting to me, is that the whole Jigsaw effort has been focused only on what the JDK needs for encapsulation and isolation, not on what the general Java community needs.   They rolled this up, over time, with casual involvement of some community members and are on the home stretch, it seems, to subject all kinds of people to all kinds of pain and broken applications as soon as JDK-9 is released and people start mindlessly upgrading.

This version of Java is breaking all kinds of software in all kinds of ways.  My personal opinion is that this is really not an answer to much of anything.  The security solutions are not real.  You can still edit Jar files.  You can still recast code with various tooling to provide access to exactly the APIs that they are trying to keep you from using.  As long as there is JNI, there is a way into the JVM with native code to do anything.  As long as there is no SecurityManager active, any jar can include as many native JNI code fragments as needed to access as much of the native computer environment as the developer desires.

All of the things that they are attempting here are blind attempts at confining access to software services in the JDK while there is really no way to do that.

Gregg

> On Mar 30, 2017, at 2:49 PM, Fabian Lange <fabian.lange at instana.com> wrote:
> 
> Hello all,
> I was quite surprised when I learned that on short notice a change
> landed to jdk9 that by default disallows agent runtime attach.
> The JDK-8177154 mentiones that the implementation is desigend to keep
> random agents out while still allowing "cooperative troubleshooting
> tools". Otherwise -XX:+DisableAttachMechanism would have been
> sufficient.
> 
> As the vendor of troubleshooting and monitoring tools, we would like
> to know how we can be considered cooperative, to be still allowed to
> use the attach API.
> As of now, we use the attach API to monitor a vast number of JVMs in the wild.
> 
> The description in the issue hints at that "self-elevation" of code
> via attach was the primary target, but that because such code could
> fork a new JVM to remote attach, this effectively cannot be prevented.
> I wonder why the self-elevation cannot be prevented using the
> SecurityManager? It would prevent VirtualMachine.loadAgent and
> variants of Runtime.exec.
> 
> With disabling the attach API loadAgent() users no longer can use any
> monitoring or troubleshooting tool that uses javaagents that use
> instrumentation (that is not only us)
> Could vendors become certified to still be allowed to invoke the API?
> Is that the idea behind cooperative troubleshooting tools?
> 
> I want to question the statement:
> 5. The change should only impact a small number of tools
> 
> Has an evaluation been performed on what tools use the API and how
> many of them are affected?
> 
> The notes also state that not resolving the jdk.attach module will not
> work because several tools use that API. I find this confusing. Aren't
> those tools also affected by turning off the loadAgent API?
> 
> I would appreciate some information on this and how we can still
> function by default in the future.
> 
> Best regards
> Fabian Lange
> 
> -- 
> Fabian Lange | VP of Engineering
> Mobile: +49 (0) 160.3673393
> 
> INSTANA Inc | 541 Jefferson Ave, Ste 100 | 94063 Redwood City, CA |
> United States
> 
> INSTANA GMBH | Hochstraße 11 | 42697 Solingen | Deutschland
> Sitz der Gesellschaft: Solingen | HRB 26637 | Amtsgericht Wuppertal
> Geschäftsführer: Mirko Novakovic | Pavlo Baron