RE: JEP411: Missing use-case: Monitoring / restricting libraries
Thanks Chris, I like that approach very much. Thanks again Markus From: Chris Hegarty Sent: den 28 april 2021 12:51 To: Markus Gronlund Cc: Lim ; Ron Pressler ; security-dev@openjdk.java.net Subject: Re: JEP411: Missing use-case: Monitoring / restricting libraries On 28 Apr 2021, at 11:38, Markus Gronlund mailto:markus.gronl...@oracle.com>> wrote: Hi Lim, JFR specific feedback can be posted to: hotspot-jfr-...@openjdk.java.net<mailto:hotspot-jfr-...@openjdk.java.net> Thanks Markus. That is the appropriate list to send JFR feedback. Just to add, I filed an Enhancement Request in JIRA, 8265962: "Evaluate adding Networking JFR events” [1], to track the possibility of adding JFR events to the JDK libraries that perform low-level networking activity (which is mostly in the purview of the networking and libraries area). If we had such, then it would be possible to monitor *all* low-level network activity performed by the platform, regardless of which higher-level library is performing the activity. Clearly such would not capture URLs, but rather the network activity that would be triggered by, say, an HTTP Client library. This seems like a more fruitful and uniform approach, rather than trying to add JFR events to, say, every HTTP library. -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8265962 Thanks Markus -Original Message- From: Lim mailto:lim.chainz11+mail...@gmail.com>> Sent: den 28 april 2021 12:18 To: Markus Gronlund mailto:markus.gronl...@oracle.com>> Cc: Ron Pressler mailto:ron.press...@oracle.com>>; security-dev@openjdk.java.net<mailto:security-dev@openjdk.java.net> Subject: Re: JEP411: Missing use-case: Monitoring / restricting libraries Hi Markus, thank you for giving me the guidance for performing the JFR programmatically. I am able to test if my use case is suitable. Where do I provide my feedback/issue of using the streamed JFR? On Wed, Apr 21, 2021 at 10:32 PM Markus Gronlund mailto:markus.gronl...@oracle.com>> wrote: If the existing event probes in the JDK does not give you the information you need, like the name of URL's, it can be a reached by building your own "custom events" via the Events API [3]. It can be harder to add events to unknown code dynamically, but it can be done and you can use java.lang.Instrument to build an agent to inject the custom event. I understand that new events can be added in code that I have control of using the Events API but in this case, which is the name of URLs is not feasible. Firstly, using a Java agent to instrument bytecode cannot be scaled because there are a lot of HTTP libraries, including the built in Java APIs and 3rd parties such as Apache HTTP, OkHttp. They can also roll their own "HTTP wrapper" if the author doesn't want dependency. In addition, these 3rd party libraries can be shaded and relocated, making it harder to target via instrumentation. Obfuscation can also have an impact on reliability of instrumentation, since obfuscation can be changed in every version and what if the obfuscation has "anti-tamper/anti-debug" features? This is not scalable if we need to monitor for each library that might call URLs. If there is a general problem area and provides a good scaling factor, and the URL information might just be such a case, it can make sense to investigate if this information can be provided directly by the JDK, by extending existing or new JFR events. I believe that the majority of the HTTP libraries, and code that roll their own are using the built in Java APIs, thus monitoring the built in API that is used for making URLs calls make sense. Then, it can be scaled to most of the libraries compared to instrumenting each one which has its own problem stated above.
RE: JEP411: Missing use-case: Monitoring / restricting libraries
Hi Lim, JFR specific feedback can be posted to: hotspot-jfr-...@openjdk.java.net Thanks Markus -Original Message- From: Lim Sent: den 28 april 2021 12:18 To: Markus Gronlund Cc: Ron Pressler ; security-dev@openjdk.java.net Subject: Re: JEP411: Missing use-case: Monitoring / restricting libraries Hi Markus, thank you for giving me the guidance for performing the JFR programmatically. I am able to test if my use case is suitable. Where do I provide my feedback/issue of using the streamed JFR? On Wed, Apr 21, 2021 at 10:32 PM Markus Gronlund wrote: > If the existing event probes in the JDK does not give you the information you > need, like the name of URL's, it can be a reached by building your own > "custom events" via the Events API [3]. It can be harder to add events to > unknown code dynamically, but it can be done and you can use > java.lang.Instrument to build an agent to inject the custom event. I understand that new events can be added in code that I have control of using the Events API but in this case, which is the name of URLs is not feasible. Firstly, using a Java agent to instrument bytecode cannot be scaled because there are a lot of HTTP libraries, including the built in Java APIs and 3rd parties such as Apache HTTP, OkHttp. They can also roll their own "HTTP wrapper" if the author doesn't want dependency. In addition, these 3rd party libraries can be shaded and relocated, making it harder to target via instrumentation. Obfuscation can also have an impact on reliability of instrumentation, since obfuscation can be changed in every version and what if the obfuscation has "anti-tamper/anti-debug" features? This is not scalable if we need to monitor for each library that might call URLs. > If there is a general problem area and provides a good scaling factor, and > the URL information might just be such a case, it can make sense to > investigate if this information can be provided directly by the JDK, by > extending existing or new JFR events. I believe that the majority of the HTTP libraries, and code that roll their own are using the built in Java APIs, thus monitoring the built in API that is used for making URLs calls make sense. Then, it can be scaled to most of the libraries compared to instrumenting each one which has its own problem stated above.
RE: JEP411: Missing use-case: Monitoring / restricting libraries
Hi Lim and Ron, Some information about JFR that can be pertinent to this discussion: JFR is flexible when it comes to control, with many entry points: command-line, jcmd, JMX, and programmatically via the Java API which I think is relevant for your use case [1] [2]. There is currently no support for JFR Event Streaming in JDK Mission Control. If the existing event probes in the JDK does not give you the information you need, like the name of URL's, it can be a reached by building your own "custom events" via the Events API [3]. It can be harder to add events to unknown code dynamically, but it can be done and you can use java.lang.Instrument to build an agent to inject the custom event. A Java Agent can be loaded dynamically, without command-line options, see [4] "Starting and Agent after VM Startup". However, this dynamic approach requires bytecode programming to some extent. You might want to take a look at the new JMC Agent that was just released might be useful as a reference [5]. If there is a general problem area and provides a good scaling factor, and the URL information might just be such a case, it can make sense to investigate if this information can be provided directly by the JDK, by extending existing or new JFR events. Thank you Markus [1] https://docs.oracle.com/en/java/javase/16/docs/api/jdk.jfr/jdk/jfr/Recording.html [2] https://docs.oracle.com/en/java/javase/16/docs/api/jdk.jfr/jdk/jfr/consumer/RecordingStream.html [3] https://docs.oracle.com/en/java/javase/16/docs/api/jdk.jfr/jdk/jfr/Event.html [4] https://docs.oracle.com/en/java/javase/16/docs/api/java.instrument/java/lang/instrument/package-summary.html [5] https://developers.redhat.com/blog/2020/10/29/collect-jdk-flight-recorder-events-at-runtime-with-jmc-agent/ -Original Message- From: security-dev On Behalf Of Ron Pressler Sent: den 21 april 2021 14:56 To: Lim Cc: security-dev@openjdk.java.net Subject: Re: JEP411: Missing use-case: Monitoring / restricting libraries P.S. In your hypothetical scenario you’re treating the library as untrusted code. In that case, even today Security Manager is not the best option because correctly creating a sandbox that is both hermetically secure against *untrusted* code (i.e. possibly malicious) and allows it to use a rich set of APIs (i.e. it isn’t a self-contained Applet) is very, very hard, and usually requires the host application to be written with the SM in mind, i.e. to use AccessController.doPrivileged; how many applications/libraries do that correctly? For rich libraries and applications, your best bet is an OS-level sandbox. The Security Manager might give you a false sense of security. — Ron > On 21 Apr 2021, at 13:28, Lim wrote: > >> Monitoring network connections can be done with JFR. It will tell you >> which classes perform the connections. It does not require a Java agent. > > Hi Ron, I read about the JFR and it required a command line argument > "-XX:StartFlightRecording" and it is not suitable since it is > distributed to the *end user*. Does JFR able capture the URLs > performed by those libraries (which can be obtained by getting the > name of URLPermission)? I have used it before in JMC and it only shows > the hostname address only. Is there an alternative besides JFR that is > capable of using programmatically means like SM such as > setSecurityManager, ability to capture logs, perform blocking in real > time? > If JFR is capable of operating *without using command line flags*, can > you please link it to the relevant documentation? Besides that, if > using JFR streams, can it be used with JMC concurrently? > >> Setting up the SM to *block* connections while also not allowing >> those libraries to disable the SM is not very easy. > > Well if those libraries are able to disable SM, those libraries are > able to circumvent the native restrictions of the operating system > too. But these mostly occur in malicious-like libraries that are less > well known or in the worst possible case, popular libraries that are > hijacked. > >> Those libraries are trusted, and monitoring is more effective than >> sandboxing for trusted code. > > I disagree to a degree, not all libraries can be vetted by the > operators of the websites, especially those who do not use those > distribution websites. This is because some of the libraries might be > obfuscated by the library authors themselves and thus unable to > determine the trustworthiness, or libraries are unknowingly tampered > by 3rd parties. Not every end user will know how to perform hash > checking of the downloaded library, even more on verifying the > signature of the library. The users implicitly trust because they > assume the distribution sites will perform checks on the library for > malicious code. They rely on users reporting the library that is > malicious. This means that there is a chance that untrustworthy code > is executed before kn
