JEP411: Missing use-case: Monitoring / restricting libraries
Lim
lim.chainz11+mailing at gmail.com
Wed Apr 28 10:18:06 UTC 2021
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
<markus.gronlund at 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.
More information about the security-dev
mailing list