On 24/03/17 11:15, Alan Bateman wrote:
> 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.
I agree that only #3 is affected. However, my opinion does indeed differ
as to what is most useful when it comes to my agent. Byteman usage
relies almost exclusively on #3:
when used with the BMUnit extension to manage unit or integration
testing the ability for BMUnit to hoist the agent into a running JVM
makes a critical difference to usability
when used for ad hoc trouble shooting of problems at the point where
they arise, either in sandbox or production deployments, it is equally
critical that the agent can be loaded without prior, explicit
preparation for that necessity
> #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.
It may well have been controversial for years as far as you regard it
but that is not necessarily grounds to take it as a the definitive
position. I discussed this very question with Marc Schoenefeld in much
the same timescale you are referring to (this was just around when he
moved from working with Red Hat's security team to working for Oracle's
security team). He was then perfectly happy with the status quo. IN
fact, he even went on to praise Byteman as a very valuable tool in his
book on Java security issues. So, before we argue what history is
relevant here (of if, indeed, we need to trawl the realms of history
when making a present decision) let's have a fuller discussion of what
the potential security problems are.
You mention the need to allow, for example, root access rather than same
gid access as a potential change that might justify this new default. I
have to (respectfully) suggest that once root access on the JVM host is
compromised then any further closing of gates is akin to Nero fiddling
in a burning citadel. The other cases you suggest are, perhaps, more
interesting. However, given that you are indeed referring to existing
mechanisms for securing access then I'd like to be sure that they are
not actually already adequate before determining that this change is
required.
The current situation already restricts command line access to 'users
with specific capabilities' i.e. the same uid and/or gid. Can you
provide a precise scenario where there will be a need to employ more
relaxed control of such capabilities. Can you also explain why, in
consequence, there is a need for the JVM to fix a hole left open by this
alternative use of existing user access controls?
I am unclear as to why you say there was never an intention to 'use the
attach API from regular applications or libraries'. Perhaps this was
just a bad design decision in the way VirtualMachine.attach or the
native code which underpins it was crafted. It's fairly clear that
having implemented this API in Java it would be open for use to load
into the current VM as well as into a foreign VM and it's hard top see
how the Genie is not out of the bottle by that point. You could, for
example, try to plug the gap by refusing to load an agent when the
target JVM is the requesting JVM. Of course, you could still then suffer
from cyclical loads via one or more intermediate JVMs so I don't think
that tactic constitutes a full remedy.
I do agree, albeit only to a small degree, JDK9 has made it easier to
use the VirtualMachine.attach API: in earlier releases the classes
needed to perform the attach were in tools.jar but not in rt.jar so were
not normally immediately available to the JDK runtime; in JDK9 they are
now in the base image. I qualify that difference as small because I
think that it is, perhaps, more an apparent than real level of
protection. Any compromise significant enough to allow rogue code into
the JVM in JDK9 (i.e. significant enough to allow dynamic loading of an
agent using VirtualMachine.attach) could equally have allowed rogue code
loaded into a JDK8 to perform the same operation by including the
VirtualMachine class in the rogue bundle.
> 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.
Well, that is indeed a good thing to consider. Perhaps that should have
been done before raising a JIRA and then posting a commit for review 3
days later? Perhaps it still needs doing?
Also, it's not the number of tools affected that counts but the impact
of the change on users of those tools vs the gains in security that
result from the change. On the debit side, I can assure you that the
former is something Red Hat consider to be very serious. It's not simply
documentation (and the need to promulgate the required understanding
beyond mere written words) it is also, as I mention in mye earlier note,
legacy and the ability to interoperate between JDK releases. On the
credit side, I'm not yet convinced that this change achieves an
improvement in security that is not available via other, better means.
Perhaps, you could provide more meat on that particular bone?
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
