Again, I want to stress that from my position we are completely ignoring desktop Java users who will update Java to JDK 9 and never know that they’ve broken something by doing that.
Java is not a server only enterprise deployed environment… Gregg > On Apr 2, 2017, at 6:39 PM, Stephen Felts <stephen.fe...@oracle.com> wrote: > > I agree with Andrew's position that if the argument is added in JDK9, it > should default to allow dynamic loading of agents. > > Arguing from the position "Isn't it already the case, however, that migrating > existing applications to JDK 9 is often going to require the use of a few new > options anyway, in order to expose internal APIs" isn't a valid argument IMO. > Although migration to JDK 9 will be painful, I think that we will get to > zero JDK 9 command line arguments. As proposed, this new argument will never > go away. > > It's highly likely that customers will have scripts that they migrate from > JDK 8 to JDK 9. We don't control that. > And many developers don't use any scripts because for many cases, they don't > care about the garbage collector or memory or whatever the scripts provide. > But they do care about product functionality provided by an agent. > > > > -----Original Message----- > From: Andrew Dinn [mailto:ad...@redhat.com] > Sent: Friday, March 31, 2017 5:46 AM > To: Mark Reinhold > Cc: jigsaw-dev@openjdk.java.net > Subject: Re: Disallowing the dynamic loading of agents by default > > Hi Mark, > > On 30/03/17 16:38, mark.reinh...@oracle.com wrote: >> // Moving the general discussion to jigsaw-dev for the record; // >> bcc'ing {hotspot-runtime,serviceability}-dev for reference. >> >> Andrew, >> >> Thanks for your feedback on this topic [1][2][3]. > > ... and thank you for your considered reply. > >> First, we apologize for the way in which this topic was raised. Our >> intent was to post a proposal for discussion prior to code review, but >> unfortunately that review was posted prematurely (as is evident by its >> inclusion of Oracle-internal e-mail addresses and URLs). > > Hmm, yes! I must say I didn't notice that. I appreciate the apology but it's > not really necessary. I certainly didn't expect any explanation to omit some > element of miscommunication and/or cock-up :-) > >> Second, I agree with your earlier analysis as to the security impact >> of this change. If an attack is possible via this vector then closing >> the vector would only slow the attack, not prevent it. > > Good, I am glad to hear there is not some terrible loop-hole at play that I > am not aware of. > >> The motivation for this change is, however, not merely to improve the >> security of the platform but to improve its integrity, which is one of >> the principal goals of the entire modularity effort. ... > > Ok, I understand the motive here although I'm still not personally convinced > by it. I'll come to the practical considerations below. Before that I'd like > to address the question of integrity at a more abstract level. > > I'm certainly not against providing -XX+/-EnableDynamicAgentLoading as a > command line option. I agree that it's probably useful for some users to have > the option to completely lock down the platform to guarantee its integrity. > It seems from what you say above that this lock-down option is only there to > provide 'belt and braces'. In other words, it is only necessary to guard > against a security breach that could be managed by other means (e.g. a > failure to control what jars go into your classpath; a failure to control > access to the JVM uid on on the JVM host machine). > I cannot fault the idea of a belt and braces lockdown per se but I am still > not convinced why that extra protection needs to be enabled /by default/. > > You specifically bring up the scenario where rogue code, once entered into > the JVM, might use the attach API to raise its privilege level. > > "As things stand today, code in any JAR file can use the > `VirtualMachine.loadAgent` API to load an agent into the JVM in which it's > running and, via that agent, break into any module it likes." > > Yet, you also acknowledge above that this merely constitutes an opportunistic > escalation of a situation that is already a serious security breach in its > own right. I don't think I follow the logic here. > > Are you saying that we need the extra braces because there is a real danger > here? one that users cannot rightly always be expected to guard against? Or > are you just being extra cautious. This is really the crux of the matter > because that extra caution has to be weighed against the extra cost of lost > opportunities to deploy agents in abnormal situations. > > n.b. I know in the case of Red Hat's middleware that this is a real cost > which will definitely arise no matter how hard we work to educate users about > the necessary advance preparation required. It is also a significant cost > because it will damage our ability to resolve certain very difficult support > issues where only an agent can provide the information needed. And that is > above above and beyond the cost of the re-education task itself. I don't > doubt other companies will be affected similarly. > > My mention above of 'abnormal' situations underlines why your argument about > integrity is somewhat moot (to me). Yes, it is important to know that > encapsulation means encapsulation -- at least, I agree that is so in /normal/ > circumstances. However, agents are clearly not normal code performing the > normal program operations of an application. Many agents are specifically > designed fro deployment in abnormal situations and perform abnormal actions. > That is precisely what provides the impetus to deploy agents dynamically. > > It is highly valuable in such circumstances, and only in those circumstances, > to be able to allow privileged agent code to /selectively/ remove certain > integrity barriers, even if -- perhaps, especially because -- any dismantling > of the normal rules of operation only happens modulo the specific licence the > agent has been crafted and configured to grant. Useful agents clearly scope > the degree to which they perturb normality to achieve abnormal results. > Careful and thoughtful users can (must) still feel safe that an agent is not > going to do catastrophic damage to the running application and the integrity > of its data and operation. Ironically, this means that deployment of my agent > is actually a relatively normal (even if infrequent) procedure for many of > our users. > > So, while I agree that platform (or even application) integrity is a valuable > property to maintain in normal program operation, I don't think those > concerns are warranted in the case of an agent that has been deliberately and > carefully deployed by those in charge of an application. I suspect we are > probably not going to agree about the proposed default on these grounds (and > I also suspect I will not be the only one to disagree with your position). > So, perhaps we would be better off moving on to pragmatic concerns. > >> I understand your points about the practical difficulties of having to >> educate users about this new option and enhance startup scripts to use >> the option only when invoking JDK 9. Isn't it already the case, >> however, that migrating existing applications to JDK 9 is often going >> to require the use of a few new options anyway, in order to expose internal >> APIs? >> If so then would it really be that much more burdensome for users also >> to think explicitly, at the same time, about whether they want to >> enable dynamic agent loading? > > If the default is reset to allow dynamic loading then I am happy to fully > endorse this change and see no significant consequences. If this change is > going to happen with your proposed default then I would very much prefer it > to be staged: introduce the flag in 9 but with the default being to allow > dynamic loading of agents (i.e. default to the status quo); reset the default > in 10 to disable loading. The benefit of that is > > aware JDK9 users can still use or ignore the option as they see fit > > unaware JDK9 users will not get hit by the change by surprise in JDK9 > > unaware JDK10 users may still get hit by surprise but by that stage any > configuration option they add to their JDK10 scripts will be compatible if > they need to switch back and forth between JDK10 and JDK9 > > implementers of agents and implementers of middleware that might benefit > from using those agents have more time to prepare their users, limiting the > potential for any such nasty surprise in JDK10 > >> This change would be disruptive to some but it's the best way we've >> found, so far, to preserve platform integrity in the face of dynamic >> agent loading. If there's a better way to do that, we'd like to know. > > No, I don't think there is a better mechanism, only a better default. > That reflects my belief that, while 'preserving platform integrity' is a > highly desirable goal, for most users it does not merit being pursued 'in the > face of dynamic agent loading'. > > 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
